DO NOT USE ANALYTICS

Solar2D General Questions/Discussion
#1

Hi fellow developers,

As you may be aware, there is a bug in analytics.init() which means that if you close the app during the init call, it crashes the next time you open it. (IOS6)

There is an assigned bug for this (18017), but as it is in the 185 “what’s up next” next bugs, I have no confidence that it will be fixed without us developers lobbying Corona!

What does this mean?
Well, it means analytics will need to be disabled in all new apps until corona fixes it!

It is especially frustrating as the latest marketing video from Corona http://www.youtube.com/watch?v=bw9JBbKN_ks&feature=youtu.be talks about the importance of anaytics in apps!

Yours, forever patient,

Anthony
[import]uid: 87194 topic_id: 32345 reply_id: 332345[/import]

#2

Damn, I want to upload next week to Apple for review - and my app has some flurry calls integrated. Hope to hear soon from Coronalabs.

Best,
Andreas
[import]uid: 107675 topic_id: 32345 reply_id: 128772[/import]

#3

Damn, I want to upload next week to Apple for review - and my app has some flurry calls integrated. Hope to hear soon from Coronalabs.

Best,
Andreas
[import]uid: 107675 topic_id: 32345 reply_id: 128772[/import]

#4

However, it doesn’t crash if [lua]UIApplicationExitsOnSuspend = false[/lua] in your build.settings, as Nevistech you noted in the previous thread you raised on this topic: (http://developer.coronalabs.com/forum/2012/10/11/analyticsinit-crash-ios6. For me, and I imagine most Corona developers, we don’t experience the issue because we have [lua]UIApplicationExitsOnSuspend = false[/lua].

I was curious why for your app it’s important for you to have [lua]UIApplicationExitsOnSuspend = true[/lua]?

  • Andrew [import]uid: 109711 topic_id: 32345 reply_id: 128867[/import]
#5

Hi Andrew,
Yes you are right. These are the reasons that I have UIApplicationExitsOnSuspend = true

  • if the home button is pressed during the main game scene, I want the app to automatically go back to the menu screen, as the user has usually deliberately quit the app. Unfortunately, when the user returns to the app, they get the main game scene again for a few hundreds of a second before there is time to go back to the menu. I’ve tried lots of ways to solve this, but it looks as if there is just not enough time to even blank the screen when the applicationSuspend system event occurs

  • When the user return to the app, I would like the splash screen to be displayed, if only for a couple of seconds. This does not happen with UIApplicationExitsOnSuspend = false

  • As a developer I want to make sure that the game is completely robust, and I’m 99.9% sure it is. However even after extensive testing, there is always the possibility that an unforeseen bug may cause something to go wrong. Worst case is that the app hangs and the user would have to reset the phone.
    Setting UIApplicationExitsOnSuspend = true just gives me that guarantee that the user can reset the game into a good state in the unlikely event something bad happens. I know some people will disagree, but it’s almost impossible to guarantee 100% bug-free code.

  • Designing an App with zero memory leaks is very very time consuming. If you set SettingUIApplicationExitsOnSuspend = false, you need to be very very sure that that the app does not memory leak, particularly if it is a very high performance app.

Cheers!

Anthony [import]uid: 87194 topic_id: 32345 reply_id: 128879[/import]

#6

Hi Anthony,

I completely understand where you’re coming from, but I respectfully disagree on all these points. :slight_smile:

First, you suggested that when a user is playing a game and presses the home button, they’ve probably “deliberately quit” the game. I disagree. Quite often, a user will press the home button while they’re playing a game because they have something else they need to do on their device (make a phone call, check or send an email, etc.). Once they’ve finished doing that, and they come back to the game, they’ll naturally expect it to be in the same state as before, i.e., if they were in the middle of a level, the game should re-open in that level just where they left off. Most games that I’ve ever tried have this behavior. If your game doesn’t, I think you’ll find your users will be disappointed very quickly, and understandably so.

Second, while I agree that you can never be sure to be completely bug-free, and that some unforeseen bug could cause your game to hang, having the game exit on suspend is, in my mind, a very sub-optimal solution because of the reason I described above. Test your app thoroughly, not just yourself on your own devices, but having friends and family and others test on their devices. With enough testing across people and devices, you should feel comfortable that there are no show-stopper bugs. If, even after that testing, some show-stopper bug did exist that caused your app to hang, the user wouldn’t have to reset their phone to fix it. On iOS, a user can also double-click the home button to bring up the list of running apps and close them individually (though I would grant that not all users know how to do this). Also, if a user doesn’t use an app for a while, eventually iOS will exit it from suspension in order to reclaim the memory for other apps the user is running. Once that happens, your game will restart from the beginning next time it’s launched.

Third, while I suppose developing an app with zero memory leaks is a bit more time consuming, I don’t think it’s unreasonably so once you’ve had some practice with it. Be disciplined about your use of global vs. local variables, destroying unneeded objects, etc., and test your memory usage whenever you make significant changes to your code (there are a number of posts around the forums with suggestions how to do this) to make sure you haven’t introduced a leak.

That’s my perspective anyway. :slight_smile:

  • Andrew [import]uid: 109711 topic_id: 32345 reply_id: 128883[/import]
#7

Hi Andrew,
Thanks for your perspective - I knew my comments would be controversial: debate is good!
Yes, I’ve done lots and lots of testing with family and friends! I’ve not received any negative comments on version 1 of my first release about quitting on pressing the home button… let’s wait and see for the next version that has just been submitted! The individual game challenges are really short (around 60-90 seconds) so people don’t seem to get annoyed with this.

A number of games I’ve played display the splash screen upon relaunching for a couple of seconds, before either resuming in a paused state with the menu screen showing and an option to continue (e.g. Jetpack joyride, Temple Run) or starting again from fresh at the main menu (e.g. Blast Monkeys). But I can’t seem to get around the issue where my old play screen is displayed before the main menu is displayed. There also seems to be slight issues with the audio. The old method of pausing audio when the system suspend event is received does not seem reliable on IOS6. So you get a short “glitch” of music before the menus screen is displayed. Maybe I’m being a perfectionist! Do you have a solution to this?

In any case, there is still a critical bug in analytics that needs fixing and I’m hoping that Corona will prioritise this!

Anthony [import]uid: 87194 topic_id: 32345 reply_id: 128931[/import]

#8

Hi Anthony,

Unfortunately I don’t have a solution to the issues you’re describing. With [lua]UIApplicationExitsOnSuspend = false[/lua], the suspending and resuming of my app is quite seamless (no issues with audio or with a screen being briefly displayed).

That said, on a suspend event, I do completely stop (not just pause) the music and dispose of the handle. Then, on a resume event, I reload the music. So it’s possible that doing something like this would help in your case.

  • Andrew [import]uid: 109711 topic_id: 32345 reply_id: 128938[/import]
#9

However, it doesn’t crash if [lua]UIApplicationExitsOnSuspend = false[/lua] in your build.settings, as Nevistech you noted in the previous thread you raised on this topic: (http://developer.coronalabs.com/forum/2012/10/11/analyticsinit-crash-ios6. For me, and I imagine most Corona developers, we don’t experience the issue because we have [lua]UIApplicationExitsOnSuspend = false[/lua].

I was curious why for your app it’s important for you to have [lua]UIApplicationExitsOnSuspend = true[/lua]?

  • Andrew [import]uid: 109711 topic_id: 32345 reply_id: 128867[/import]
#10

Hi Andrew,
Yes you are right. These are the reasons that I have UIApplicationExitsOnSuspend = true

  • if the home button is pressed during the main game scene, I want the app to automatically go back to the menu screen, as the user has usually deliberately quit the app. Unfortunately, when the user returns to the app, they get the main game scene again for a few hundreds of a second before there is time to go back to the menu. I’ve tried lots of ways to solve this, but it looks as if there is just not enough time to even blank the screen when the applicationSuspend system event occurs

  • When the user return to the app, I would like the splash screen to be displayed, if only for a couple of seconds. This does not happen with UIApplicationExitsOnSuspend = false

  • As a developer I want to make sure that the game is completely robust, and I’m 99.9% sure it is. However even after extensive testing, there is always the possibility that an unforeseen bug may cause something to go wrong. Worst case is that the app hangs and the user would have to reset the phone.
    Setting UIApplicationExitsOnSuspend = true just gives me that guarantee that the user can reset the game into a good state in the unlikely event something bad happens. I know some people will disagree, but it’s almost impossible to guarantee 100% bug-free code.

  • Designing an App with zero memory leaks is very very time consuming. If you set SettingUIApplicationExitsOnSuspend = false, you need to be very very sure that that the app does not memory leak, particularly if it is a very high performance app.

Cheers!

Anthony [import]uid: 87194 topic_id: 32345 reply_id: 128879[/import]

#11

Hi Anthony,

I completely understand where you’re coming from, but I respectfully disagree on all these points. :slight_smile:

First, you suggested that when a user is playing a game and presses the home button, they’ve probably “deliberately quit” the game. I disagree. Quite often, a user will press the home button while they’re playing a game because they have something else they need to do on their device (make a phone call, check or send an email, etc.). Once they’ve finished doing that, and they come back to the game, they’ll naturally expect it to be in the same state as before, i.e., if they were in the middle of a level, the game should re-open in that level just where they left off. Most games that I’ve ever tried have this behavior. If your game doesn’t, I think you’ll find your users will be disappointed very quickly, and understandably so.

Second, while I agree that you can never be sure to be completely bug-free, and that some unforeseen bug could cause your game to hang, having the game exit on suspend is, in my mind, a very sub-optimal solution because of the reason I described above. Test your app thoroughly, not just yourself on your own devices, but having friends and family and others test on their devices. With enough testing across people and devices, you should feel comfortable that there are no show-stopper bugs. If, even after that testing, some show-stopper bug did exist that caused your app to hang, the user wouldn’t have to reset their phone to fix it. On iOS, a user can also double-click the home button to bring up the list of running apps and close them individually (though I would grant that not all users know how to do this). Also, if a user doesn’t use an app for a while, eventually iOS will exit it from suspension in order to reclaim the memory for other apps the user is running. Once that happens, your game will restart from the beginning next time it’s launched.

Third, while I suppose developing an app with zero memory leaks is a bit more time consuming, I don’t think it’s unreasonably so once you’ve had some practice with it. Be disciplined about your use of global vs. local variables, destroying unneeded objects, etc., and test your memory usage whenever you make significant changes to your code (there are a number of posts around the forums with suggestions how to do this) to make sure you haven’t introduced a leak.

That’s my perspective anyway. :slight_smile:

  • Andrew [import]uid: 109711 topic_id: 32345 reply_id: 128883[/import]
#12

Hi Andrew,
Thanks for your perspective - I knew my comments would be controversial: debate is good!
Yes, I’ve done lots and lots of testing with family and friends! I’ve not received any negative comments on version 1 of my first release about quitting on pressing the home button… let’s wait and see for the next version that has just been submitted! The individual game challenges are really short (around 60-90 seconds) so people don’t seem to get annoyed with this.

A number of games I’ve played display the splash screen upon relaunching for a couple of seconds, before either resuming in a paused state with the menu screen showing and an option to continue (e.g. Jetpack joyride, Temple Run) or starting again from fresh at the main menu (e.g. Blast Monkeys). But I can’t seem to get around the issue where my old play screen is displayed before the main menu is displayed. There also seems to be slight issues with the audio. The old method of pausing audio when the system suspend event is received does not seem reliable on IOS6. So you get a short “glitch” of music before the menus screen is displayed. Maybe I’m being a perfectionist! Do you have a solution to this?

In any case, there is still a critical bug in analytics that needs fixing and I’m hoping that Corona will prioritise this!

Anthony [import]uid: 87194 topic_id: 32345 reply_id: 128931[/import]

#13

Hi Anthony,

Unfortunately I don’t have a solution to the issues you’re describing. With [lua]UIApplicationExitsOnSuspend = false[/lua], the suspending and resuming of my app is quite seamless (no issues with audio or with a screen being briefly displayed).

That said, on a suspend event, I do completely stop (not just pause) the music and dispose of the handle. Then, on a resume event, I reload the music. So it’s possible that doing something like this would help in your case.

  • Andrew [import]uid: 109711 topic_id: 32345 reply_id: 128938[/import]