I'm trying to bring Ruboto IRB in line with the latest Ruboto code. I'm noticing significant problems with the service code. We do have a service test, but it creates its own RubotoService subclass (avoiding the problems I'm seeing). I've got fixes for most of what is broken, but the trick is getting both use case working. The reason for this is the fact that onCreate is the typical entry method for Activities and it works for subclasses of RubotoService too (because you determine the script and class names from the subclass name). When you try to create a service from inside of Ruby (i.e., using RubotoService directly), the information about the class name is contained in the intent which is not known in onCreate. In those cases, we need to wait until onStartCommand to set up the remote delegate. Anyway, here's a list of some of the things I'm working on fixing:
I should note the the current service.test_rb doesn't use/test service.rb.
(#648) Updated service.rb code to match activity.rb
(#648) Added preOnStartCommand and preOnBind; condition preOnCreate t…
…o only function if not using RubotoService
(#648) Added preOnStartCommand and preOnBind when building RubotoService
(#648) Convert to use start_ruboto_service
I'll see if this revised test passes and then I'll create a few more tests.
Note: On services created directly from RubotoService: At the moment, I'm not calling onCreate in the script because the script isn't loaded until after onCreate. I'm sure we could, but I'm not sure how to avoid a second call to super.
(#648) New test for class based service delegate
Hi @rscottm !
How is this coming along? I'd like to push a release this weekend. We should support both use cases by then.
We support both cases now. The only question is whether we should call onCreate a "second" time for scripts that couldn't be loaded until onStartCommand. In that case:
1) onCreate is called. We can't open the script because there is not intent to specify the the script. We just call super.
2) onStartCommand is called. We can now load the script. Do we want to call onCreate in the ScriptingContainer now before we call onStartCommand?
Note 1: the one issue in calling it is that it will cause a second call to onCreate super.
Note 2: the one issue in not calling it is that it will not execute code that the developer puts into onCreate.
We're currently not calling onCreate the second time. It is a one line change to call it. I don't know if there are implications for Note 1.
The committed code does not load the script at all when using start_ruboto_service. The service_test fails. Do you have uncommitted code, @rscottm ?
My last checkin was a month ago:
Renamed service_test to service_gen_class_test to clarify the difference from other service tests
Perhaps I did it wrong. I was assuming that it would remove service_test when I renamed the file though git. That test is no longer supposed to be there. The tests seemed to pass at the time (718). Could the file have come back in through a subsequent checkin? Or did I just need to remove it explicitly?
OK, ee66058 only adds the new test, but was intended to remove the old. I'll remove the duplicate, but both fail currently along with ServiceBlockTest and ServiceClassTest. Are you able to run the tests successfully in your workspace?
I haven't run the tests on my machine in awhile. It's always just been easier to get things running and then monitor the Travis tests. That's what I don't understand. The tests worked when I submitted the code, and they've worked several times since then based on tests run after other code was checked in. The last set of services tests that failed seem to be due to a build failure. Therefore, I'm assuming the service tests work, and that we've got other problems that are causing the builds to fail.
Are they failing on your local run of the tests? I can try to get the tests running on my machine. I can't make any guarantees. I do my development in a VM and the tests take many hours and usually fail due to sone resource issue.
Looking at the travis build history, the service tests worked until very recently, long after your last commit, so it must be something else.
They are failing for me locally, so I'll investigate here.
I'll also see if I can get travis green by allowing known failures. That should help in detecting new errors.
I did a change in RubotoService to initialize JRuby if it was not already initialised.
Closing this issue since it seems it is solved.