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

iOS Play sound on Resume

X

xArtx

macrumors 6502a
Original poster
Mar 30, 2012
764
1
Hi Guys,
Just something I thought I'd share that I haven't seen in an App before.
Seven broken guidelines!!!


No seriously, This flag being set here:
Code: 
- (void)applicationDidBecomeActive:(UIApplication *)application
{
    resumed = 1;
}

And then in your main loop,

Code: 
if (resumed == 1) {
// play a sound here
resumed = 0;
} // resumed

Now you have a sound that indicates the transition from a static frame,
to your program being active when it is resumed from suspend...
or that was the idea.
It also sounds when you answer an iOS alert dialogue such as whether or
not to allow Location Services, because the App is suspended.
Then the sound feels like a confirmation of the OK button being pushed.
Another is Ending a phone call where the phone call interrupted your App.
It feels like the App knew you hung up as soon as you end the call,
as if the App was waiting rather than iOS. Not bad for the investment.
 
Duncan C

Duncan C

macrumors 6502a
Jan 21, 2008
853
0
Northern Virginia
Wouldn't that get annoying?

I think that would start to drive me nuts pretty fast, and I would delete any app that did that.

xArtx said:
Hi Guys,
Just something I thought I'd share that I haven't seen in an App before.
Seven broken guidelines!!!


No seriously, This flag being set here:
Code: 
- (void)applicationDidBecomeActive:(UIApplication *)application
{
    resumed = 1;
}

And then in your main loop,

Code: 
if (resumed == 1) {
// play a sound here
resumed = 0;
} // resumed

Now you have a sound that indicates the transition from a static frame,
to your program being active when it is resumed from suspend...
or that was the idea.
It also sounds when you answer an iOS alert dialogue such as whether or
not to allow Location Services, because the App is suspended.
Then the sound feels like a confirmation of the OK button being pushed.
Another is Ending a phone call where the phone call interrupted your App.
It feels like the App knew you hung up as soon as you end the call,
as if the App was waiting rather than iOS. Not bad for the investment.
Click to expand...
 
dejo

dejo

Moderator emeritus
Sep 2, 2004
15,982
452
The Centennial State
So, which guideline are we breaking this time?

Also, any particular reason resumed is an int (presumably) and not a BOOL? Where did you define it?

And where is your "main loop"?
 
X

xArtx

macrumors 6502a
Original poster
Mar 30, 2012
764
1
I don't know if you can use external variables without plain C, but in my case declared in
Viewcontroller, and then extern int in Appdelegate.

Bool, int, both the same thing. The value can only be one or zero. I think it's because I came from asm and like to see 1 or zero, but I beleive
You can do the same things with a bool,
Like decrement it to false.
 
Duncan C

Duncan C

macrumors 6502a
Jan 21, 2008
853
0
Northern Virginia
xArtx said:
I don't know if you can use external variables without plain C, but in my case declared in
Viewcontroller, and then extern int in Appdelegate.

Bool, int, both the same thing. The value can only be one or zero. I think it's because I came from asm and like to see 1 or zero, but I beleive
You can do the same things with a bool,
Like decrement it to false.
Click to expand...

Objective C is pure superset of C, so anything you can do in C, you can do in Objective C (including extern declarations.)

I too am an old assembler developer (6502, Z80, 80x86, 680x0, a little VAX here and there...) However, I've come to see the value of strong typing. If you need to represent a true/false value, BOOL is a much better choice. It makes the code self-documenting, it gives the compiler more info so it can find nonsense expressions, etc.
 
X

xArtx

macrumors 6502a
Original poster
Mar 30, 2012
764
1
Duncan C said:
Objective C is pure superset of C, so anything you can do in C, you can do in Objective C (including extern declarations.)

I too am an old assembler developer (6502, Z80, 80x86, 680x0, a little VAX here and there...) However, I've come to see the value of strong typing. If you need to represent a true/false value, BOOL is a much better choice. It makes the code self-documenting, it gives the compiler more info so it can find nonsense expressions, etc.
Click to expand...

I've used them when it is part of sample code, but it is really just an integer yes?
Otherwise we might as well cut to the chase and call it a Bit variable type,
and C would be much more awesome.

Funnily enough, if it were a bit variable I'd be racing to use it to save
memory which would only really matter on an old asm platform.

Now I will have to find out what happens if you increment a Bool that has a value of 1.
 
Duncan C

Duncan C

macrumors 6502a
Jan 21, 2008
853
0
Northern Virginia
xArtx said:
I've used them when it is part of sample code, but it is really just an integer yes?
Otherwise we might as well cut to the chase and call it a Bit variable type,
and C would be much more awesome.

Funnily enough, if it were a bit variable I'd be racing to use it to save
memory which would only really matter on an old asm platform.

Now I will have to find out what happens if you increment a Bool that has a value of 1.
Click to expand...

The compiler won't let you increment a BOOL. That's a good thing.
 
dejo

dejo

Moderator emeritus
Sep 2, 2004
15,982
452
The Centennial State
Duncan C said:
The compiler won't let you increment a BOOL. That's a good thing.
Click to expand...

Unfortunately, I think it will let you increment a BOOL. The following code compiled for me with no warning/errors/crashes:
Code: 
BOOL resumedBOOL = YES;
resumedBOOL++;

In case it matters, BOOL is actually defined as typedef signed char BOOL;
 
X

xArtx

macrumors 6502a
Original poster
Mar 30, 2012
764
1
dejo said:
Unfortunately, I think it will let you increment a BOOL. The following code compiled for me with no warning/errors/crashes:
Code: 
BOOL resumedBOOL = YES;
resumedBOOL++;

In case it matters, BOOL is actually defined as typedef signed char BOOL;
Click to expand...

It's only unfortunate if the result is 2.
If the result is 0, that's the same as a compliment, probably isn't though.
 
dejo

dejo

Moderator emeritus
Sep 2, 2004
15,982
452
The Centennial State
xArtx said:
It's only unfortunate if the result is 2.
If the result is 0, that's the same as a compliment, probably isn't though.
Click to expand...

When printed as a %d, the result is 2, and not 0!

Code: 
BOOL resumedBOOL = YES;
resumedBOOL++;
NSLog(@"resumedBOOL = %d", resumedBOOL);
if (resumedBOOL) {
	NSLog(@"resumedBOOL is true");
} else {
	NSLog(@"resumedBOOL is not true");
}

Output:
Code: 
resumedBOOL = 2
resumedBOOL is true

Further testing indicates that as long as resumedBOOL is not 0, it's considered true/YES.

So, using BOOL doesn't provide as much protection/functionality as one would hope.
 
PhoneyDeveloper

PhoneyDeveloper

macrumors 68040
Sep 2, 2008
3,114
93
That is unfortunately inherited from C where the behavior is "0 is false" and "not 0 is true".

If you change your code to

Code: 
if (resumedBOOL == YES) {

you can get into trouble. However, it is convenient and a common idiom to check for nil pointers in the same way

Code: 
if (somePointer) {

Strictly speaking this should be

Code: 
if (somePointer != nil) {

which generates the expected boolean expression.

Using ints to hold boolean values is a C language anachronism. In Objective-C code it is best to use BOOL and to only assign values to it of YES and NO, and to take care that your use of boolean expressions also results in values of YES and NO, like

Code: 
BOOL pointerIsNotNill = pointer != nil;

The reality though is that all of our non-trivial apps use third party code and you can't guarantee that every use of a BOOL or boolean expression follows these rules.
 
Duncan C

Duncan C

macrumors 6502a
Jan 21, 2008
853
0
Northern Virginia
PhoneyDeveloper said:
That is unfortunately inherited from C where the behavior is "0 is false" and "not 0 is true".

If you change your code to

Code: 
if (resumedBOOL == YES) {

you can get into trouble. However, it is convenient and a common idiom to check for nil pointers in the same way

Code: 
if (somePointer) {

Strictly speaking this should be

Code: 
if (somePointer != nil) {

which generates the expected boolean expression.

Using ints to hold boolean values is a C language anachronism. In Objective-C code it is best to use BOOL and to only assign values to it of YES and NO, and to take care that your use of boolean expressions also results in values of YES and NO, like

Code: 
BOOL pointerIsNotNill = pointer != nil;

The reality though is that all of our non-trivial apps use third party code and you can't guarantee that every use of a BOOL or boolean expression follows these rules.
Click to expand...


TRUE and FALSE are also valid constant values in Objective C that are equivalent to YES and NO.
 
PhoneyDeveloper

PhoneyDeveloper

macrumors 68040
Sep 2, 2008
3,114
93
I stay away from TRUE and FALSE. I only use YES, NO in Objective-C code. I think YES, NO are more idiomatic.
 
X

xArtx

macrumors 6502a
Original poster
Mar 30, 2012
764
1
Turns out I'm not the first to fuss over the waste of seven bits:

Code: 
typedef enum {
  Flag1 = 1,
  Flag2 = 1 << 1,
  Flag3 = 1 << 2,
  Flag4 = 1 << 3,
  Flag5 = 1 << 4,
  Flag6 = 1 << 5,
  Flag7 = 1 << 6,
  Flag8 = 1 << 7
} Flags;

char *printFlags(Flags flags) {

  if ( Flags & Flag1 ) { 
    return "Flag1 has been set";
  } else

....

}

int main(void) {
  printf( "%s", printFlags( Flag1 | Flag2 | Flag3 ) );
}

Now I've seen everything.
 
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