Some input concerning the future of offline/client apps

[paul121]

I've been trying to catch myself up with development of the offline app, trying to get a grasp for the client and native repositories. Good to see that these pieces are under very active development!! Opening a general issue instead of commenting on many related issues.

Happy to report I have everything built and running locally off a docker instance of farmOS. This is my first time playing around in farmOS itself, getting a good feel for it. I'm going to 'pitch' my demo to our farm soon - I have added some areas, crops in various stages, and animals (chickens) configured with the Egg module. Playing around in this 'backend' of farmOS, it's great. Theres a learning curve, but it makes sense. I like the analogy of the 'backend' or 'admin' view.

This makes me quite excited about the development of the API and Client apps. On a farm where multiple users are involved it makes sense they only know a smaller part of the interface. I like that their is a push to combine the client and native repositories... lots of discussion in #30. https://github.com/farmOS/farmOS-native/issues/54 confirms that many needed features are in development. :) Reading "A Path Towards a New Architecture" starts to clear up where things may be headed.. laughing at

...Or is this becoming a whole new framework unto itself???

SO I'm trying to wrap my head around how this will work. See if I understand correctly:

• It seems like each Drupal module could include the JS necessary to render forms/interfaces in the client app for adding/editing logs concerned with those assets. This makes intuitive sense, although I don't have the understanding for Drupal/Vue/Cordova to see understand the logistics behind this
• As a developer, I would create/extend modules/assets and (optionally) supply code to manipulate these features in the offline app.
• Merging the repositories also answers some questions concerning auto-deployment of apps for app store

Some considerations:

• What about the ability to make custom views in the app? Perhaps I have a morning chore list; it would be nice to have one view to submit egg counts from two animal assets, and mark the animals fed at the same time. All in a preset form? This seems like it may be best viewed as a custom quick form, that is visible in the app
• The ability to set defaults within a form - a quantity in a certain view, for example -preset the measurement as weight and unit as pounds.

Overall, very cool. I thought I would be forking these repositories, adding my custom pieces, and managing a separate app on separate app stores - yikes! Excited to see this foundation in place. Hoping to do some tinkering over the holidays...

[jgaehring]

@paul121 Thanks for taking such an interest and doing a deep dive into the issues queue! I'm impressed you were able to make any sense of my ramblings here. :smile:

It seems like each Drupal module could include the JS necessary to render forms/interfaces in the client app for adding/editing logs concerned with those assets. This makes intuitive sense, although I don't have the understanding for Drupal/Vue/Cordova to see understand the logistics behind this

That's one idea we're toying with, coming out of some discussion in #38. The real logistical question is how will Drupal deliver the necessary JS to the client (securely), in whatever context the client is being rendered. I frankly don't know how that'll work, but I'd like to try!

As a developer, I would create/extend modules/assets and (optionally) supply code to manipulate these features in the offline app.

My goal, eventually, is to make this project as extensible as possible so that other developers can add to it as easily as possible, without having to start from scratch every time. In that respect, it's my hope to try to mirror the modularity and extensibility of Drupal.

What about the ability to make custom views in the app? Perhaps I have a morning chore list; it would be nice to have one view to submit egg counts from two animal assets, and mark the animals fed at the same time. All in a preset form? This seems like it may be best viewed as a custom quick form, that is visible in the app

Yes! Mike and I have talked a lot about this sort of thing (he's working on some "Quick Forms" as a part of farmOS, with a similar design in mind). To me, this is of the utmost importance when it comes to farming software. The problems faced by modern farmers are so incredibly varied and precise in nature, that the software has to be designed in a modular way to match. Modeling the data is one thing, but as a frontend developer I'm keenly interested in how we model the interaction, in conjunction with the data model. And that demands being able to accommodate many varied interactions under tight constraints. Presets are good way to get the data you need out of level of interaction that's possible. When a farmer's out of wifi range, in a light rain or intense sun, bent over a row and trying to keep track of how many seedlings they've transplanted so far, there's now time to be messing around with settings and options.

I look forward to seeing what you're able to make of all this, and would be grateful for any feedback. Feel free to ping me here or on Riot if you have questions!

[mstenta]

I would love to explore these things too! The egg quick form might be a great place to start - because it's such a simple one. Perhaps exploring that one specifically will help us to elucidate what these kind of modular integrations would look like, and start to think about some of the specifics with a concrete (and relatively simple) goal in mind.

For context, some things to consider: quick forms in farmOS can be provided by modules, and they can be enabled/disabled within farmOS at /farm/quick/configure. So, in an ideal world, the client app would be able to call out to farmOS for extra features, and the egg module would provide its quick form, which would then be integrated into the app (somehow). This would mean that some people would see the egg quick form in the app (those who have it in their farmOS), and some wouldn't.

This kind of integration/interaction would require some code in both sides (client and server) to facilitate transfer of things. This would be a good place to start putting some thought into... perhaps we should start a new issue to start thinking through those specifics?

[paul121]

Modeling the data is one thing, but as a frontend developer I'm keenly interested in how we model the interaction, in conjunction with the data model.

@jgaehring yes!! I'm glad the project has your perspective from the interaction side of things. So so important. The quick forms sound like a good way to tie this in. @mstenta sounds great. For now I will try and create a custom module that provides a quick form. It will be a good way for me to get an better understanding of the Drupal side of things.

At the farm we will be doing some research on fermented chicken feed. The research will have quite a few data points... weighing feed given, feed leftover, water consumption, egg production, bird weight, etc. I don't know all the details yet, but hoping to use farmOS to collect this info.

At some point it would be great to get this into a mobile app for easy data collection :) Starting a new issue may be good to organize all those thoughts, yes!

[jgaehring]

At the farm we will be doing some research on fermented chicken feed. The research will have quite a few data points... weighing feed given, feed leftover, water consumption, egg production, bird weight, etc.

Sounds awesome! I hadn't heard of that practice before. I'll have to do some reading... :wink:

At some point it would be great to get this into a mobile app for easy data collection :) Starting a new issue may be good to organize all those thoughts, yes!

That seems like a good idea to me. I'm here to help wherever I can. Perhaps once you have a good idea what you want to do, we could take a call and look more closely at the requirements. @alexadamsmith might be a good person to include, b/c I know he's thinking of creating some extensions over the winter too (harvest related). Another thing that should be helpful might be the work I'm doing in the 3rd sprint of https://github.com/farmOS/farmOS-native/issues/54. I think having a proper start to the "app shell", along with some basic navigation built in, should give us a better idea what direction to take when incorporating new client modules.

[paul121]

Thank you @jgaehring ! Sounds great. I agree, once you are in that 3rd sprint more of these ideas can be addressed. Many exciting things in the works!

[mstenta]

(Transferring all issues from old repository. See https://github.com/farmOS/farmOS-native/issues/92)

[jgaehring]

Closing this in favor of #217.