Data components documentation release

Hi everyone,

We have recently released a new update that brings life to data components: one of our most powerful features developed yet. They are essentially reusable components with data-related logic built-in, eliminating the need for app-level data variables. You can use pre-made data components from the marketplace or even create your own.

Along with the release, we are happy to announce that Data Components now have the appropriate documentation that you can find here: Data components. If you are willing to create your own data components, we have created a detailed guide: Creating a data component - Data components.

We are looking forward to hearing what you think about Data Components and the Docs!

1 Like

How does this impact performance (memory and speed) compared to reading a data component once and then copying it to an app variable for use throughout the app?

Some solid tested figures would be nice rather than feelings or “it should”.

1 Like

The performance threshold is pretty much the same. What makes data components different, is that the logic that fetches data from a data resource automatically assigns it to the variables and removes the need to configure that yourself. (except the mapping, of course, which is still a lot faster than using the logic functions).

@Kirill_Leventcov, great documentation. I might have been just too curious maybe a few weeks ago, but playing around with the accordion component back then, I already could see the system. But with the help of this documentation we can create our own components more easily.

Another thing that is on my mind that inputs for data configurator are always data resources.

Let’s assume, I have a bunch of records, that I want to only download once during the app session. When we navigate away from the page do the component unmount? Or do they stay available?
I mean if we navigate away from a page the data variables are cleared as they are only available on that specific page. Is this the case with component private data variables?

If this is the case, it seems to me that I would

  1. need to recreate my data resource as an on device storage
  2. sync the e.g. Firestore filtered collection to the local data resource
  3. use that in the data configurator for the component right?

Thanks. If I get bored I might change, but having already done this for 130 variables I will leave it as is :slight_smile: Sounds great though, one for next time.

The 130 variables allows me to switch the language of my App. It just reads a language collection from Firestore.

I thought it was something like that. I am using a similar approach. Have an app Text document collection and when user changes language download the documents and save to local storage. From then I can load it next time from device.

Nice. My app is pretty much a single use thing for most people, so not much need to worry about saving bandwidth or anything for subsequent logins.

How does using data components affect the size of the end build? Does it create a larger file in the end or a smaller one, or no difference?

Great question, the build size should not be much different, as far as I am aware.

@Mihaly_Toth

we navigate away from a page the data variables are cleared as they are only available on that specific page.

The private data variables are only accessible within the Data Component. It makes it easy to connect to your data resource without having to setup the data variables yourself. In a sense, we bring a concept of re-using components, and not just variables.

That’s too bad. We really need to figure out how to get appgyver apps small enough to be considered good apps.

1 Like

How much is app size really a factor? I have never looked into it.

Good question: I have two Android apps that are exactly the same and identical:

With AppGyver: 198MB
With Kodular: 35MB

Now, in the final installation, the result is as follows:

With AppGyver: 221MB
With Kodular: 43MB

That is why there is a lot of comment about the sizes of compilations, because there are stores that only require up to a certain size, and they have to change them to the AAB format, so that at least it weighs less and does not exceed the 200MB allowed in some stores.

1 Like

I have had a couple beta testers tell me they had to uninstall my app at 58MB because it was too large and consuming too much RAM. I think the default loops in Appgyver data variables had a lot to do with the RAM part and had to remove all the loops. But even after removing loops, building the app, and installing it on my phone, it consumed more data and RAM than any app on my phone.

1 Like

A personal observation:
I managed to create a new data component following to the instructions in the documentation, and it worked just fine with on-device storage. However, I couldn’t get the component to work with a Firebase data source until I connected the component’s id field using a formula (see pic below).
image
Should the connection work just by dragging the id field when using an external data source? Or have I done some mistake in the configuration somewhere? Any ideas, anyone?

I managed to connect the Collapsible Group Basic List component with the data via API, but already ran into a bug. Most of the time, on of the groups doesn’t react to the touch input and stays closed. Sometimes it works and both of the groups open, but most of the time it doesn’t (without changing anything in either Appgyver or on the backend). Couldn’t figure out why.

Her’s a short video:

@Dejan Thanks a lot for reporting this! Could you please create a bug report at https://tracker.appgyver.com/ so I can put that under investigation? Here is guidance in case you are unsure: Issue reporting guidelines