I have a use case in which I can't initialize JobManager in Application.onCreate (I'm using android-job in a library and I don't have access to the application's Application class).
Now, if I schedule a job which is run after the application closes, the job will be run without initializing JobManager and I will get the exception:
IllegalStateException: You need to call create() at least once to create the singleton
This can easily be solved if JobManager is created before being used in PlatformJobService.onStartJob using the service context if the singleton doesn't already exist.
Could you add this change to the project? I could do it myself if you approve.
Interesting, but how do you attach your job creator in this case? To be clear, I could prevent the crash (what's actually better), but your job won't run.
I attach the the Jobcreator once my library is initialized. The problem is my library isn't necessarily initialized in Application.onCreate, the user can initialize it in any arbitrary place, such as Activity.onCreate.
But then you job won't run at all. The JobManager will ask all JobCreators if they can create a job for the specific tag. Your creator won't be called, because you haven't registered the creator, yet.
I only see the option that you need to tell the users of your lib to initialize your library in the Application.onCreate() method.
Let me know if you have a better idea.
If for example I call JobCreator in Activity.onCreate, the JobManager will call my JobCreator form then on and jobs are scheduled and run. The problem is when application is not running, this exception (IllegalStateException) is raised. I may initialize JobCreator in a service so as it exists even when app is closed but if user force-close the app, this exception will happen again.
As I cannot prevent occurrence of this exception in this scenario, I need this exception to not happen. At least even f my jobs are not running, the app still can have its normal behaviour.
@vRallev
Fixed in version 1.0.10. Thanks for your feedback!
Thanks for update. It is really helping.
By the way, I am curious about a solution that completely resolve this issue. I mean while google gcmNetworkManager has no problem even when the app which is using it for scheduling its task is closed; it seems to me that this problem can be completely avoided here too. Maybe by relying on some sort of permanent storage (like SharedPref, a file or DB) for handling jobs when AlarmManager is used for scheduling jobs.
Am I correct or there is some other consideration that I missed?
My guess is that GCM is using reflection internally. We at Evernote decided against it. Class name mappings may change between versions and could result in undesired behavior.
Most helpful comment
Fixed in version
1.0.10. Thanks for your feedback!