SOLVED Updating iOS app with added table rows causes hang;
Agent Argyle
Member, PRO Posts: 188
Has anyone had issues with iOS adhoc or testflight build updates hanging - especially when you add rows to a table?
I just added a new level to my game and now the level select screen hangs with the spinning wheel showing when running the updated app. If I delete the app and re-install it, the app does not hang. However, this is not ideal as I will want to be able to release updates with new levels without users having to delete the old version first.
I suspect that the problem has to do with an added row to a table that didn't exist previously. I say this because the level select system I am using uses a table to store info about the levels, and the info for my new level is not being displayed on screen in the updated app.
The system is either this one or one just like it: http://www.deepblueapps.com/?product=easy-level-select-with-stars (there are several floating around that are more or less identical it seems.)
I am wondering about what gets saved and what gets overwritten with respect to tables when updating vs deleting/reinstalling and if there is something I can do in my code to make sure that the table gets updated properly when updating the app.
thanks!
Comments
Gross, I was worrying about stuff like that.
One option I've been planning mentally is to just:
1) duplicate the table for the update and then;
2) add the new needed update rows to the duplicate table and then;
3) change the behaviors to point to the new duplicate table instead and then;
4) add a one-time "Update" button interrupt screen to the app so that;
5) on first launch of the updated app the button will run a one-time copy from the old deprecated table onto the new expanded table
Then if the tables are separate files, the old one won't get over-written and the data will still be accessible.
Oh... interesting.. That sounds like it might do the trick
Hopefully! Please report back if it does. Contingency planning for worries like that is slowing down my own progress a lot. If it proves successful it will help me move ahead too. I could call that risk resolved.
Will let you know if it works for sure. For now I am going to see if any other responses come in before trying it though because that may end up being a lot of tedious work.
@Moik, In the meantime, I tried simply changing the name of the table in the hopes that that would be sufficient. But, alas, no.
I can't help feeling like this is a bug though- I don't recall this happening before.
Solved it! It's really simple. Just add a rule that says If the number of table rows is less than the number of levels, add a row to the table. Anyway, thanks for your idea @Moik - luckily the fix is simpler.
Interesting. Thanks!
I suspect your code was out of order and you were trying to access a row/ column that didn't exist yet. This is similar to trying to address a row/column zero. It will cause a hang/crash. With your new code you are adding the row when the number goes up and then the code that access that info fires and now see the info needed. I suspect before the code was trying to read the info before it was there.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
@Lost_Oasis_Games Yes, my thoughts exactly. That is what I meant when I wrote in my original post:
And yes, since I solved the problem with a conditional that checks to see if the table has as many rows as there are levels, that pretty much clinches it.
By the way, I added the row manually before updating the app. So it should be there. And in fact it IS there when you delete the app and reinstall from the same build. But when you just update, the table does not get updated along with the rest of the app.
So it seems that updating apps retains the previously installed apps' tables whereas deleting and re-installing overwrites them. I imagine this is meant to keep users' data intact, though it would be more ideal if the update process ran a delta on the table and updated whatever has changed.