Advertise here




Advertise here

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Badges

RLScott @ @ @ @

About

Username
RLScott
Joined
Visits
821
Last Active
Roles
Tutorial Authors, Registered Users
Points
108
Posts
1,667
Badges
13
  • Audio input filling only partial buffers in iOS 9.1

    We just finished rushing through an emergency critical bug update for an audio input app that broke in iOS 9.1. If you are using Audio Queues, take note.

    The Audio Queue callback function that delivers another buffer has a parameter that specifies the number of elements in the buffer. In previous iOS versions, this parameter was always equal to the allocated size of the buffer. In other words, every buffer was completely filled. Starting in iOS 9.1, the system now in exercising its option to deliver partially-filled buffers to you in that Audio Queue callback. If you had assumed (as I did) that for normal PCM format raw audio data, every buffer was full, you will get some really strange results.
  • Re: Game - NSTimer - need to use a different thread?

    No, don't use another thread and don't use NSTimer. Instead use:
    NSDate *startDate = [NSDate date];  //..when the game starts..
    NSDate *endDate = [NSDate date];  //..when the game ends, or when user clicks..
    NSTimeInterval gameTime = [endDate timeIntervalSinceDate: startDate];  //..subtracts dates
    
  • Re: "salting" a string?

    Here is a limitation of all "salting" operations meant to increase security. In serious encryption applications the designers should always assume that everything except the password could be known to an attacker. That includes the salt and the hash algorithm. Unless you are going to personalize the salt for each user and keep it just as secure as the user's password. So if the attacker knows the salt then he can simply modify his cracking machine to pre-salt all the candidate passwords. If he is going to run through a dictionary of likely passwords then he can still do that with the salt added on.

  • Re: Does local variable´s keep it´s value after end of Instance implementation

    I read that in C - if you have an local variable declared inside a function. After that function ends the variables set inside that function looses its value. So say you have an "int name = 100;" after the function ends that will be set to null.

    Is it the same for instance methods in objective-C? if I declare "int name = 100" after that instance method is ended will it be set to null? unless i make it a static variable?
    A local variable will not be set to null when a function or method exits. It will simply cease to exist. You can't reference it outside the method, and the next time you enter that method a brand new instance of that local variable will be created which will have absolutely nothing to do with the previous instance. If it has an initializer as you have shown then it will be initialized upon entry.

    Static, as you said, implies visibility only within the file where it is declared. But an ivar is not a global. A global variable has only one instance forever. An ivar has a different instance for each instance of the class to which it belongs.