NPE in android version


#1

Hi,

One of my users is getting this on a Galaxy S5:

java.lang.NullPointerException
  at com.shinobicontrols.charts.y.onSurfaceChanged(Unknown Source)
       at com.shinobicontrols.charts.GLTextureView$f.l(Unknown Source)
     at com.shinobicontrols.charts.GLTextureView$f.run(Unknown Source)

Can you look into it? I don’t know how to reproduce it really, but I’ll try to ask my user to see if he has a pattern for it.

Thanks,

Radu


#2

Hi Radu,

Thanks for letting us know about this. There’s not a lot to go on here so if your user is able to reproduce it consistently it would be great to know the steps involved.

That said, it looks like the kind of error you get when using a ChartView (as opposed to a ChartFragment) and don’t forward on lifecycle calls from the containing Activity or Fragment. Are you using ChartView at all?

Kind regards,

Patrick


#3

I’m only using SupportChartFragment. I asked my user and he said the crash happened when he let the phone go to sleep, but I haven’t had a chance to try and reproduce it yet.


#4

If you send me a version of the library without the line numbers stripped, I can bundle that in the app and give you a more meaningful stacktrace…

My user has got this exception 9 times already so it shouldn’t be too hard for him to reproduce it.


#5

Hi Radu,

We’ll have to look into this a little further but what I think is happening is that when your user’s phone is going to sleep the Activity is being destroyed along with the ChartFragment. The savedInstanceState bundle coming into the Activity when it is recreated, however, is not null. As such, using a check such as if (savedInstanceState == null) to decide whether or not to set the chart up again may not be adequate - you may not be using this yourself but we do this in our sample apps.

Off the top of my head (in the interest of getting you a quick answer) you may be able to add something to the bundle that is saved when the Activity is destroyed and check it when a new one is created later on. Inspecting the ShinobiChart that is returned from the ChartFragment may be an alternative option (if it already has axes then it’s already be set up etc.).

I’ll let you know once we’ve investigated this issue further.

Kind regards,

Patrick


#6

Interesting thought - I’ll try to reproduce this by forcing activities to be killed when navigating away from them (from the developer options). 


#7

Hello . Are there any updates on this issue?

I successfully get a step by step workflow to get this exception.

So mainly this is what happens.

Have a screen with a ViewPager on it and a FragmentStatePagerAdapter for that viewpager. On the adapter have a Fragment with a ChartView or ShinobiChart inside, and some Axis set on it, let’s say we want to display a chart with random data.

After that while the screen with ViewPager and adapter are visible, send the application to background so the fragments get detached. Resuming the application causes the following crash.

Any ideas or incomming workaround for this?

java.lang.NullPointerException
            at com.shinobicontrols.charts.y.onSurfaceChanged(SourceFile:177)
            at com.shinobicontrols.charts.GLTextureView$f.l(SourceFile:1539)
            at com.shinobicontrols.charts.GLTextureView$f.run(SourceFile:1267)

#8

Hello . Are there any updates on this issue?

I successfully get a step by step workflow to get this exception.

So mainly this is what happens.

Have a screen with a ViewPager on it and a FragmentStatePagerAdapter for that viewpager. On the adapter have a Fragment with a ChartView or ShinobiChart inside, and some Axis set on it, let’s say we want to display a chart with random data.

After that while the screen with ViewPager and adapter are visible, send the application to background so the fragments get detached. Resuming the application causes the following crash.

Any ideas or incomming workaround for this?

java.lang.NullPointerException
            at com.shinobicontrols.charts.y.onSurfaceChanged(SourceFile:177)
            at com.shinobicontrols.charts.GLTextureView$f.l(SourceFile:1539)
            at com.shinobicontrols.charts.GLTextureView$f.run(SourceFile:1267)

#9

Hello . Are there any updates on this issue?

I successfully get a step by step workflow to get this exception.

So mainly this is what happens.

Have a screen with a ViewPager on it and a FragmentStatePagerAdapter for that viewpager. On the adapter have a Fragment with a ChartView or ShinobiChart inside, and some Axis set on it, let’s say we want to display a chart with random data.

After that, while the screen with ViewPager is visible, send the application to background (pressing Home) so the fragments get detached. Resuming the application causes the following crash.

Any ideas or incomming workaround for this?

java.lang.NullPointerException
            at com.shinobicontrols.charts.y.onSurfaceChanged(SourceFile:177)
            at com.shinobicontrols.charts.GLTextureView$f.l(SourceFile:1539)
            at com.shinobicontrols.charts.GLTextureView$f.run(SourceFile:1267)

#10

Hi guys,

I’ve looked into this a little further and as suspected it is to do with the Activity and Fragment being destroyed.

@Arkde - with respect to your issue, if you are using ChartViews, are you forwarding the lifecycle calls from the Fragment to the ChartView? There is more detail in the API docs but most important is forwarding onPause and onResume - without doing this you will get a null pointer exception when putting the app in the background and coming back to it.

It seems the issue Radu is seeing is when the Activity and the ChartFragment are being destroyed (and yes, that option in the Developer Options is very useful for testing this situation). As the Android docs say “This can happen either because the activity is finishing (someone called finish() on it) or because the system is temporarily destroying this instance of the activity to save space.” In the latter case, when the app is resumed the savedInstanceState Bundle in the onCreate method of your Activity will be non-null.

What I suspect is happening is that the Activity is making an assumption that the chart is still alive. In a lot of our samples we have opted for simplicity to demonstrate particular features and so do most of the setting up of the chart in the Activity. What this does mean is in situations like the one above, when you resume the app, the chart is blank - the set up code isn’t run because it is guarded by an if (savedInstanceState == null) call but because the ChartFragment was destroyed so was the chart! The better approach is to create a subclass of ChartFragment and do your set up code in the onCreate method. As the ChartFragment is retained over configuration changes, this method is only called when the Fragment is created. Equally, the Fragment’s onDestroy method isn’t called for configuration changes (such as rotating the device). Our  CustomDataAdapter  sample app is an example of subclassing the ChartFragment.

I may of course be way off the mark but without seeing your app’s code I can’t say for definite. Hopefully though this will give you some pointers as to how best handle the full lifecycle of your app’s Activities and Fragments.

Kind regards,

Patrick


#11

Indeed it worked what you’ve suggested to @Arkde 

@Arkde - with respect to your issue, if you are using ChartViews, are you forwarding the lifecycle calls from the Fragment to the ChartView? There is more detail in the API docs but most important is forwarding onPause and onResume - without doing this you will get a null pointer exception when putting the app in the background and coming back to it.


#12

Am also getting this same issue while the phone is idle, and then when i click on the app i get this exception

09-04 11:30:02.981    3051-3383/? E/EnterpriseContainerManager﹕ ContainerPolicy Service is not yet ready!!!

09-04 11:30:04.516    3628-3628/? E/GestureService﹕ updateFlags started

09-04 11:30:04.516    3628-3628/? E/GestureService﹕ bVertical = false

09-04 11:30:04.516    3628-3628/? E/GestureService﹕ bHorizontal = false

09-04 11:30:05.656    3051-3489/? E/EnterpriseContainerManager﹕ ContainerPolicy Service is not yet ready!!!

09-04 11:30:05.741  18538-18791/? E/AndroidRuntime﹕ FATAL EXCEPTION: GLThread 43871

    Process: com.verizontelematics.indrivemobile, PID: 18538

    java.lang.NullPointerException

            at com.shinobicontrols.charts.y.onSurfaceChanged(SourceFile:185)

            at com.shinobicontrols.charts.GLTextureView$f.l(SourceFile:1598)

            at com.shinobicontrols.charts.GLTextureView$f.run(SourceFile:1310)

09-04 11:30:05.866    3051-3505/? E/EnterpriseContainerManager﹕ ContainerPolicy Service is not yet ready!!!

09-04 11:30:06.101   3051-20857/? E/android.os.Debug﹕ !@Dumpstate > sdumpstate -k -t -z -d -o /data/log/dumpstate_app_error

09-04 11:30:08.316    3051-3154/? E/ViewRootImpl﹕ sendUserActionEvent() mView == null

09-04 11:30:08.721   3051-31019/? E/EnterpriseContainerManager﹕ ContainerPolicy Service is not yet ready!!!


#13

Hi bijeshcj,

Are you using a ChartView or a ChartFragment?

If the former you need to forward on the enclosing Activity or Fragment life-cycle calls to the ChartView, specifically onPause and onResume.

You’ll also get this error if you are trying to redraw the chart, after it has been paused (say, by the phone being idle), but before it has been resumed, even when using a ChartFragment. In such circumstances you would need to move any redrawChart calls (or calls that automatically redraw the chart) to after the chart has been resumed.

Hope that helps.

Kind regards,

Patrick