Want advice on NSURLSession command line tool

[Daryle Walker]

Here’s what I got so far:

> @import Foundation;
> #include 
> #include 
> 
> int   returnCode = EXIT_SUCCESS;
> bool  shouldExit = false;
> 
> int main(int argc, const char * argv[]) {
> if (argc != 2) {
> fprintf(stderr, "Usage: %s URL\n", argv[0]);
> returnCode = EXIT_FAILURE;
> goto finish;
> }
> 
> @autoreleasepool {
> NSRunLoop * const  runLoop = [NSRunLoop currentRunLoop];
> NSURLSession * const   session = [NSURLSession 
> sessionWithConfiguration:[NSURLSessionConfiguration 
> ephemeralSessionConfiguration] delegate:nil delegateQueue:[NSOperationQueue 
> mainQueue]];
> NSURLSessionDownloadTask * const  task = [session 
> downloadTaskWithURL:[NSURL URLWithString:[NSString 
> stringWithUTF8String:argv[1]]] completionHandler:^(NSURL *location, 
> NSURLResponse *response, NSError *error) {
> if (error) {
> fprintf(stderr, "Error, downloading: %s\n", 
> error.localizedFailureReason.UTF8String ?: 
> error.localizedDescription.UTF8String);
> returnCode = EXIT_FAILURE;
> } else {
> NSURL * const  finalLocation = [NSURL 
> fileURLWithPath:response.suggestedFilename isDirectory:NO];
> 
> [[NSFileManager defaultManager] moveItemAtURL:location 
> toURL:finalLocation error:&error];
> if (error) {
> fprintf(stderr, "Error, copying: %s\n", 
> error.localizedFailureReason.UTF8String ?: 
> error.localizedDescription.UTF8String);
> returnCode = EXIT_FAILURE;
> } else {
> fprintf(stdout, "%s\n", finalLocation.path.UTF8String);
> }
> }
> shouldExit = true;
> }];
> 
> if (!task) {
> returnCode = EXIT_FAILURE;
> goto finish;
> }
> [task resume];
> while (!shouldExit && [runLoop runMode:NSDefaultRunLoopMode 
> beforeDate:[NSDate distantFuture]])
> ;
> }
> 
> finish:
> return returnCode;
> }

1. Is this an acceptable way to use a run loop in a command-line tool?
2. Is it OK to break an @autoreleasepool with a goto?
3. Is UTF-8 the standard to convert between NSString and whatever goes to/from 
the Terminal? I’ve seen it in various 3rd-party code.
4. When I run the tool with the same URL twice, the “Error, copying” line is 
triggered since the file already exists. However, the file-name within the 
error reason is the one in “location,” when it should be the one from 
“finalLocation”. (Especially funny since the file-name in “location” changes 
every run.) Has anyone else seen that before? Is this a bug?
5. Should I be using “localizedFailureReason” over “localizedDescription” when 
printing errors?
6. Is an ephemeral session the best option? What if I someday add options for 
proxies, cookies, etc. (like curl or wget)?
7. Is there a standard routine that moves files and renames them when 
necessary? (The API would need a NSURL** parameter to give the developer the 
file’s actual final location.) Moving files to the Trash is an example of 
Apple’s code renaming when needed during a move.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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

Experiences using Chromium Embedded Framework?

[Juanjo Conti]

Have anyone used CEF from Objective-C or Swift? Any tip or recommendations?

Thanks,

-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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: Scrolling Text Field Class for Logging?

[Jens Alfke]

> On Mar 18, 2015, at 10:34 AM, Dave  wrote:
> 
> Is there a Class/Subclass available to do this or do I need to write my own?

You need to write your own, but it’s not hard. Just check the scroll position 
before appending the text; if it was at the bottom before, scroll it to the 
bottom again.

—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

Scrolling Text Field Class for Logging?

[Dave]

Hi All,

I have a Detailed Activity Window in my Application which logs detailed 
information into a Scrolling Text Field. I’d like to have it work the same way 
in which the XCode Log Windows works, e.g. it fills the visible text field and 
then starts scrolling, if the user clicks in the Scroll Bar, it stops scrolling 
but lines are still logged. If the user Scrolls to the end of the field, it 
starts Scrolling again.

Is there a Class/Subclass available to do this or do I need to write my own?
___

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: Text fields bound to numerical property - commas in number

[Ken Thomases]

On Mar 18, 2015, at 7:56 AM, Jonathan Taylor  
wrote:

> I have a text field in my GUI bound to a property of type 'double'. The text 
> field does not have any explicit number formatter attached to it. When I set 
> the property e.g. to 22000 then it appears in the text field as:
> 22,000
> OK, fair enough, maybe the default formatting behaviour of text fields has 
> changed. The problem is that when I alter that value (but leaving it in the 
> same style), so for example I change it to:
> 22,001
> then the value of my property is set to 22. In other words, the comma is not 
> being parsed correctly to treat the whole text string as a number.
> 
> This behaviour seems very strange and inconsistent. Is this something that 
> people are familiar with? I imagine I could solve this by putting an explicit 
> number formatter on every text field, but I have rather a lot of them and so 
> would prefer not to do this! I'm also concerned that this is indicative of 
> some subtler underlying problem that I should maybe understand rather than 
> hide.
> 
> Can anyone advise at all?

The short answer is: you have to use an NSNumberFormatter for correct behavior.

What is happening with your current setup is that the binding is fetching the 
value of the property using KVC.  KVC has to wrap scalar types like double into 
objects, so the value of your property is coming through as an NSNumber.  Then, 
the text field binding does the equivalent of theTextField.objectValue = 
theNSNumber.  In the absence of a formatter, the control (or, more accurately, 
its cell) has no choice but to get a string from the object by calling 
-description on it.

Now, -description is not really very reliable as to how it formats the value of 
the object it's called on.  Apparently, -[NSNumber description] has changed 
over time to include a thousands separator.  My guess is that this change 
occurred in 10.8.  There is stuff in the 10.8 release notes for Foundation and 
Core Foundation about more localization being done when strings are formatted.  
The change may also be that NSNumber has started using +[NSString 
localizedStringWithFormat:] rather than +[NSString stringWithFormat:] when it 
constructs its description.

When editing finishes, the text field's binding uses KVC to set its new object 
value on the property.  The new object value is a string, since that's all the 
text field knows to store edited text as.  (It doesn't know it's editing a 
number.  That's precisely the role an NSNumberFormatter would fill.)  
Eventually, KVC gets to a scalar-typed property and has to unbox the value.  It 
knows the property is a double, so it invokes -doubleValue on the object.  
Not-so-coincidentally, NSString responds to -doubleValue.  However, it's not 
very sophisticated about how it parses its contents into a double.  In 
particular, it doesn't handle thousands separators.  Also, it would probably be 
confused about a string which was formatted (or typed by the user) according to 
a locale that uses a character other than period ('.') as the decimal separator.

So, the round trip is broken.  The proper fix is to use an NSNumberFormatter.

Regards,
Ken


___

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

Text fields bound to numerical property - commas in number

[Jonathan Taylor]

I've come back to some old code that I haven't used for a while, and in the 
meantime I've done several OS upgrades and Xcode upgrades so plenty has 
changed, but my code is behaving in a strange way that I'm sure it didn't used 
to.

I have a text field in my GUI bound to a property of type 'double'. The text 
field does not have any explicit number formatter attached to it. When I set 
the property e.g. to 22000 then it appears in the text field as:
22,000
OK, fair enough, maybe the default formatting behaviour of text fields has 
changed. The problem is that when I alter that value (but leaving it in the 
same style), so for example I change it to:
22,001
then the value of my property is set to 22. In other words, the comma is not 
being parsed correctly to treat the whole text string as a number.

This behaviour seems very strange and inconsistent. Is this something that 
people are familiar with? I imagine I could solve this by putting an explicit 
number formatter on every text field, but I have rather a lot of them and so 
would prefer not to do this! I'm also concerned that this is indicative of some 
subtler underlying problem that I should maybe understand rather than hide.

Can anyone advise at all?
Cheers
Jonny.
___

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