Debugging remote add--ons

Re: Debugging remote add--ons

by Dani Palou -
Number of replies: 8
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Hi Tim,

I'm glad you found the problem!

Placing all the code in a single file was a deliberate decision we made. It has 2 reasons:

  1. The app only needs to execute 1 file that has a fixed name, there's no need to iterate over all the files in the ZIP file and execute them.
  2. We can control the order of the file content, so the module declaration (main.js) is at the start of the file. Otherwise we'd have to look for the main.js (it could have a different name!) and load it first.

Please notice we have a gulp task to automatically build the remote addon, and this process already creates this addon.js file. Please see:

https://docs.moodle.org/dev/Moodle_Mobile_Remote_add-ons#Automatic_packaging

Kind regards,

Dani

Average of ratings: -
In reply to Dani Palou

Re: Debugging remote add--ons

by Tim Williams -
Picture of Plugin developers
Yes, I'm now using the gulp task to do this.

I see your point about addon.js, but it's making debugging a real pain, since the line numbers I get are in addon.js rather than the actual line number from the real file. So I have to extract the addon.js from the zip file, find the line and then search for it in the actual source code. Is there any way of persuading MoodleMobile to work with the real files and ignore addon.js in a some kind of debug mode?

Also, if the other js files aren't used, why are they still included in the addon.js by the gulp task? Surely they should be excluded.
Average of ratings: -
In reply to Tim Williams

Re: Debugging remote add--ons

by Dani Palou -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Hi Tim,

to debug the addon we recommend you to test it in the development environment, before building the addon. We always try to debug it in Chromium because it's faster, but some issues can only be reproduced in a real device. If the error only happens after the addon is built then there is no other choice as checking the addon.js file, I'm sorry.

Regarding not including the JS files, you're right. I created an issue:

https://tracker.moodle.org/browse/MOBILE-2241

Thanks,

Dani

Average of ratings: -
In reply to Dani Palou

Re: Debugging remote add--ons

by Tim Williams -
Picture of Plugin developers
Re addons.js, I can see that some developers may prefer to split there code up, but I like to keep things as simple and direct as possible. Is there any reason why I shouldn't simply put all my code into addons.js to start with and dispense with the gulp build process since the only thing it does from my point of view is to complicate debugging, something I'm already finding to be quite a painful process.

I've got Chromium set up all ready, it helps a bit, but I'm finding MoodleMobile addon development to be very difficult to get to grips with. I've written an Android apps from scratch using Cordova as well as having done Apps directly using straight java code so I'm not unfamiliar with phone app development. I think my main complaint is that it's very difficult to identify where problems are if you haven't set something up right. That will probably get easier as I learn more, but the learning curve is extremely steep compared what I'm used to when learning something new.
Average of ratings: -
In reply to Tim Williams

Re: Debugging remote add--ons

by Dani Palou -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Hi Tim,

if an addon is simple then it might be easier to put all the code in the addon.js file. We like to keep it in different files because it's easier to maintain and work with, at least for us. 

For example, mod/assign has thousands of lines of code. If someone has to implement a complex module like this one, it will be way easier to work with if the files are split instead of having a single file with thousands of lines.

Please take into account that the gulp task does more things besides building the addon.js file. It also compiles the sass files into a css file, and treats the language files to add the required prefix.

We know it's hard to start with MoodleMobile development, specially because there are a lot of different libraries and frameworks involved: cordova, angular, ionic, npm, bower, gulp, etc. Our gulp tasks were created because it is a must to be able to keep code split into separate files, and we don't want to include hundreds of files into the Mobile app (and in case of remote addons this becomes even harder for the reasons I explained in a previous post). Ionic 3 by default also has a build task to compile everything into a single file, so it's not just us.

Kind regards,

Dani

Average of ratings: -
In reply to Dani Palou

Re: Debugging remote add--ons

by Tim Williams -
Picture of Plugin developers
In which case a "debug" mode where plugins can be run "raw" so that you can see the real line numbers and source of the errors seems like an essential addition. Other software which has this kind of consolidation for performance will usually have such a mode to make development easier so that you can directly trace errors to the original source.
Average of ratings: -
In reply to Dani Palou

Re: Debugging remote add--ons

by Tim Williams -
Picture of Plugin developers
My other suggestion is that you need to give more consideration to finding ways to lower the barriers inherent in writing a remote addon. One of the joys of working with Moodle is that for the most part plugin development has quite a low barrier of entry, but it doesn't feel that way with MoodleMobile.

The basic build environment and dev tools needed aren't much of a issue (at least for me), it's not so different to stuff I've dealt with before. I can live with debugging issues caused by code consolidation for addon.js, it's irritating and costs extra time but I know how to work around it.

What I'm finding difficult is getting my head around how MoodleMobile "hangs together", the execution paths are not at all clear to me and this leads to debugging even simple problems being very time consuming. I'm not saying the design is in any way wrong, it's just feels really alien compared to what I'm used to both in Moodle and with the other mobile development work that I've done and right now there just isn't enough documentation explaining how things work to be able to get past that barrier. It feels like you need a very deep understanding of MoodleMobile in order to write addons, far deeper than is necessary for regular Moodle plugins.

I've followed the existing tutorials, but they give me very little handle on what to do when something doesn't work as expected or how to go beyond the very specific examples. If there is more out there, please point me at it, because my extensive searches have failed to find it. I have delved into the MoodleMobile source code, but there aren't enough comments in it really help.

For me, if you want to encourage existing plugin developers to support the app, then you need to find ways to make it easier for them to do so, since I suspect many of the developers who write Moodle plugins will hit the same roadblock which I feel that I'm hitting. I can get past this if I choose to invest the time, but the question I'm now having to ask myself is if it's worth the effort to do so. I'd like to add mobile app support, but cost of adding it is far higher than I initially anticipated.

This is not a complaint or a request for a major design change, just a point for discussion which I hope will inform future development decision.
Average of ratings: -
In reply to Tim Williams

Re: Debugging remote add--ons

by Juan Leyva -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hi Tim,

yes, we are aware that developing remote add-ons it's not easy at all. 

We are working on several ways to try to improve it, we are targeting Moodle 3.5 for a solution (something like developing server-side PHP code so app pages can be rendered on the server)

I'll publish in the forum soon about our plans to the new Moodle Mobile app (updated to Ionic3)

Juan

Average of ratings: -
In reply to Juan Leyva

Re: Debugging remote add--ons

by Tim Williams -
Picture of Plugin developers
Thanks Juan, my second comment above was written before seeing this. I'll look forward to the improvements. My secondary concern is that this seems to be a bit of an afterthought, when it should have been part of the initial design process.

On thing that would be really handy right now would be a better tutorial. The existing tutorial doesn't cover what I suspect most developers are going to want to do, which is to add Mobile support to an existing activity module. The choice of a notes module which seems to be divorced from a specific activity is rather curious.

Trying to decypher what's going for an activity module on by looking at the code of an existing activity module is far from easy.

A stripped down "fill in the blanks template" which contains the minimum quantity of code with plenty of comments telling you what each bit does would be really handy.
Average of ratings: -