There is a bug in the latest version of maxjournal, where it sometimes will skip reading in your journals upon starting maxjournal. Simply, for some users after upgrade, and for all others after a full reboot of the iPad, when starting maxjournal again it will skip the step of reading in the current journals from storage. Obviously this isn’t good and it has scared the users who experienced it into thinking their journals have been deleted.
Well, this isn’t the case, the journals exist. The quick fix is to simply do a complete shutdown of maxjournal. As some of you may know, when you close an app on the iPad, it simply places the app into the background running list. It doesn’t actually fully close. In this instance, after closing maxjournal you’ll need to show the list of apps in the background (double-tap the Home button), and tap and hold on maxjournal – then tap the red minus button to FULLY close maxjournal. Then just restart maxjournal – all journals will show. If it doesn’t work first try, just do it again. After journals show again, the only instance where they may seem to disappear again is after a FULL iPad system shutdown (i.e. press and hold Home and Sleep buttons until the iPad turns itself off.) Simply follow the steps above again.
Luckily Apple is fantastic when it comes to reviewing app updates in a situation like this – we submitted the fix to them yesterday and they promised to review and get it live today! Apple can be pretty great when it comes to this kind of thing.
For those technically minded (or developers) who are interesting in learning from our mistakes, here’s a basic breakdown of what we did wrong:
We created a fix for our longer term crashing bug recently. That bug was the result of an orphaned pointer to journal data – when maxjournal starts it reads in all journals from disk. In the bug version, if the iPad needs to clean memory it would remove some background memory in maxjournal, including the View that contains the list (array) of journals. Upon restarting maxjournal (bringing it to the foreground) maxjournal would rebuild this (now) missing screen – and part of the initialization of that screen includes reading the journals again from disk. The problem was in the fact that an open journal might be pointing to that list of journals. Once the missing screen rebuilt, a new list of journals was created, and the open journal would suddenly be pointing to a non-existence reference to a journal. (Everything was recreated – but the open journal didn’t know that! It was pointing to an old ‘address’ for a journal, causing crashing.)
In our bug fix, we simply added a variable saying ‘we’ve already created a list of journals, if someone asks you to re-initiatalize because of memory management, do NOT rebuild the list of journals!’. The problem was a timing issue – the code to check to see if we need to rebuild the list of journals was created in a separate CPU thread, but the variable being set to record the fact that initialization had already happened, was being set in the main thread. On normal running of the app the timing between the separate thread and the main thread works just fine. After upgrade, or restart of the iPad, the timing between the 2 threads would tend to reverse – meaning the ‘we’ve already initialized’ variable could possibly be set BEFORE the creation of the list of journals. The overall effect – ‘hey, I’ve already initialized, who needs to read in the list of journals? not me!” – leaving an empty list of journals.
The simple fix – the initialization variable needed to be set in the same thread as the building of the list of journals. !
