Collect: Looking for a quick fix for a dreadful NullPointerException bug

Development
1

Hi,

I've been making slight ad-hoc modifications on ODK Collect for a
project, starting from version 1.1.7.

I ran into a crasher bug that I first thought was caused by my added
code. But then I traced it and I couldn't see how it could be related to
what I had done, so I tried the "pure and original" ODK Collect and it
exhibits the same issue.

I have already reported it in the bug tracker, but I urgently need to
find a quick DIY fix, no matter how dirty.
So that's why I'm asking here, not in order to spam about the bug.

The problem is that when returning from the Camera activity initiated by
an ImageWidget, if the process hosting the FormEntrtActivity has been
killed while taking the picture, when it is recreated it causes a
NullPointerException at the very beginning of
FormEntryActivity.refreshCurrentView() (called by onCreate()) because
the static variable mFormController is null (well, actually not
because is it null but because somebody assumed it wouldn't be).

Here's the bug report:
http://code.google.com/p/opendatakit/issues/detail?id=642&sort=-id

The question is, does anybody have any idea of how this could be fixed?
A comment in onRetainNonConfigurationInstance() says there's supposedly
no need to return mFormController because it is static (something I
don't understand: what sort of magic is supposed to keep a static
variable of a process that is killed?). But even if it was possible to
pass back mFormController, I've verified that
onRetainNonConfigurationInstance doesn't even ever get called in the
first place in the cases when the crash then occurs.

Actually, could the real cause of the problem be just that
onRetainNonConfigurationInstance is not called? It is not guaranteed
to be called and documentation says it shouldn't be relied upon. The
question is, does Collect rely upon it? I'm not sure about that.

Can I save it into the bundle in onSaveInstanceState and extract it from
there in onCreate? Actually I don't understand the difference between
what can be passed back through onSaveInstanceState and what cannot. I
mean, is it possible to put into the bundle anything that you can return
via onRetainNonConfigurationInstance? Or are there some things that only
can be stored with one of the two mechanisms?

If it is not possible to maintain mFormController, what else could one
do? Save the partially filled form and the reload it? is this already
being done under other circumstances, so that I may start from there?

Basically, I would appreciate any enlightenment that would help me find
a fix for this problem.

By the way, it's been a long time since version 1.1.7 was released and I
was convinced I had read somewhere about a 2.0 version in development. I
thought I'd have a look at the source code to compare it to the 1.1.7
code, but I can't find it anywhere neither at sourceforge nor at
opendatakit.org. Did I dream about it?

thanks
m.

2

I'll take a look at this in 1.2. Given the way javarosa and the app are
written, it may be difficult to fix.

The "default" branch of ODK Collect is 1.2. That is the active development
tip for ODK Collect 1

The 2.0 work is entirely different and will be a mash-up of ODK Collect and
locally and remotely modifiable data tables (based off ODK Tables, which is
a generic implementation of some of the concepts from ODK Clinic). It is
not yet stable enough -- even for developer previews.

Mitch

ยทยทยท On Mon, Jul 16, 2012 at 3:43 PM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:

Hi,

I've been making slight ad-hoc modifications on ODK Collect for a project,
starting from version 1.1.7.

I ran into a crasher bug that I first thought was caused by my added code.
But then I traced it and I couldn't see how it could be related to what I
had done, so I tried the "pure and original" ODK Collect and it exhibits
the same issue.

I have already reported it in the bug tracker, but I urgently need to find
a quick DIY fix, no matter how dirty.
So that's why I'm asking here, not in order to spam about the bug.

The problem is that when returning from the Camera activity initiated by
an ImageWidget, if the process hosting the FormEntrtActivity has been
killed while taking the picture, when it is recreated it causes a
NullPointerException at the very beginning of FormEntryActivity.**refreshCurrentView()
(called by onCreate()) because the static variable mFormController is null
(well, actually not because is it null but because somebody assumed it
wouldn't be).

Here's the bug report:
http://code.google.com/p/**opendatakit/issues/detail?id=**642&sort=-idhttp://code.google.com/p/opendatakit/issues/detail?id=642&sort=-id

The question is, does anybody have any idea of how this could be fixed?
A comment in onRetainNonConfigurationInstance() says there's supposedly
no need to return mFormController because it is static (something I don't
understand: what sort of magic is supposed to keep a static variable of a
process that is killed?). But even if it was possible to pass back
mFormController, I've verified that onRetainNonConfigurationInstance
doesn't even ever get called in the first place in the cases when the crash
then occurs.

Actually, could the real cause of the problem be just that
onRetainNonConfigurationInstan**ce is not called? It is not guaranteed
to be called and documentation says it shouldn't be relied upon. The
question is, does Collect rely upon it? I'm not sure about that.

Can I save it into the bundle in onSaveInstanceState and extract it from
there in onCreate? Actually I don't understand the difference between what
can be passed back through onSaveInstanceState and what cannot. I mean, is
it possible to put into the bundle anything that you can return via
onRetainNonConfigurationInstan**ce? Or are there some things that only
can be stored with one of the two mechanisms?

If it is not possible to maintain mFormController, what else could one do?
Save the partially filled form and the reload it? is this already being
done under other circumstances, so that I may start from there?

Basically, I would appreciate any enlightenment that would help me find a
fix for this problem.

By the way, it's been a long time since version 1.1.7 was released and I
was convinced I had read somewhere about a 2.0 version in development. I
thought I'd have a look at the source code to compare it to the 1.1.7 code,
but I can't find it anywhere neither at sourceforge nor at opendatakit.org.
Did I dream about it?

thanks
m.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com