Do not load forms in JavaRosa at launch about briefcase HOT 9 CLOSED

Form name is embedded in the XML. You could avoid this if you scan and load the form name into a database (and just scan for differences).

from briefcase.

Thanks @mitchellsundt! Any other reason why Briefcase would try to load the form? Or rather, why was it done this way to begin with?

from briefcase.

The original coding intentionally avoided any embedded database and relied upon the directory structure to deduce what was in the storage area. The database was added later to improve the pull / push efficiency. And its use was never extended to other areas of the code (higher priorities).

From a usability standpoint, improving the pull / push speed impacts the viability of the app for user-interface-mediated interactions (because users have to sit and monitor the app for task completion after they click, e.g., "Pull"). For CLI interactions, where you might have this running in a polling script, start-up time could become more critical to acceptance. Especially if the intention is to rapidly migrate data into another backend process (e.g, implementing a publisher via ODK Briefcase).

And users can always prune their briefcase storage area by moving the forms they are rarely interested in into a different storage folder (via dragging). Only if the user is accessing all forms does this become a significant issue.

from briefcase.

@rclakmal Interested in taking this on?

from briefcase.

Yes. Will look into this :-)

from briefcase.

Gentlemen.. Couldn't look in to this until today. But starting off now...!

from briefcase.

@icemc Any chance you can take a look at this issue for the next release?

from briefcase.

@yanokwa,

So based on my understanding of the code:

• when starting briefcase, it read and parse form file to get: form id, form name, form version. form name will be used in the combobox display, form id + form version used in the equals and hashcode which will be used in the combobox creation (there’s internal calls to equals i think inside combobox code).

• we can skip the parsing and change the implementation to use md5 hash of the form file for equals and form’s filename in the form name
  — pros: maybe less coding, but a lot of ifs and flags
  — cons: lots of ifs and flags

• the other approach is creating database record for the form definition and replace the parsing with reading database
  — pros: no parsing
  — cons: need to sync physical file and db when opening briefcase

Another simpler other option is creating cache for parsed form definition. I'm proposing this because I notice that one method that build the form definition list is being called 4 times. So if you have 4 forms locally, then each will be parsed 4 times (16 parsing process). Method: FileSystemUtils.getBriefcaseFormList().

from briefcase.

I like the cache option. And as you described in our chat, we should not just have a basic XML parse because "because the BriefcaseFormDefinition needs the JavaRosaParserWrapper and you can’t easily create the parser without parsing the form definition XML". Maybe put a cache folder in the Briefcase storage directory?

I am still concerned that doing this before we load the UI. Can you file that as a separate issue? I think the solution is to move that work to a background thread.

from briefcase.