Menstruation cycle tracking

Hello friends! Is there any menstruation cycle tracking templates in Adalo?

Hey there @Joyce

Not that I know of. However, the logic could be followed from this: Period Calculator | Always®

Date picker for last period start date - Period length number - menstrual cycle number.

Since I don’t have periods :rofl: I’m not quite sure to calculate from the day the last period started + 28 or if you count 28 days after the last period ended.

But hopefully, this should give you a starting point.

1 Like

1 more question. How to count the day’s difference between 2 “period start dates”?

Sure but it depends on how you’re doing this for your users.

I’m sure there’s an easy way but I’m thinking of a bunch of random ideas and I’m not quite sure the best way without knowing the use case.

Can you explain the ideal functionality so that I can try to understand how it’s supposed to work?

Like walk me through the steps your user takes and what actions you need to happen if possible.

Hi friend, thank you for your reply!
This is the flow. Hope U understand :joy:
user input A & B every month.
I need to know how to set the formula for x, y and z. Thank you!!

HI @Joyce,
Not in Adalo right now, but from top of my mind there is a way of doing this. Is the small “a” in the formula the “A of this month”? Just making sure I know the whole process :smiley: .

I will make a video as soon as I leave my “Bruce Wayne” job :D.

@Flawless beat me to it, my process is basically the same :smiley: I just use different collections to tidy up the process, gives less load to collections also.

1 Like

I see.

You’ll need a number parameter called “period days” to calculate how long a period lasts and then a number parameter called “menstrual cycle” to get the days difference between this month’s period start date and last month’s period start date.

This is how you can display Y:

For your button, make a list of periods but only grab the last 1 by sorting by period start date newest to oldest and setting the maximum number of items to 1.

Set the action on the button to link to the next screen and you’ll see that the previous ‘period’ is now available on the next screen.

Set the form to create a new period:

Add an “update” action after the create action. You need to add 2 formulas to calculate the 2 number parameters. For “period days” use New Period > End Date MINUS New Period > Start Date. For “Menstrual cycle” use New Period - Start Date MINUS Current Period > Start Date.

“New Period” is the new one you’re creating and “Current Period” is the one from last month.

This is what it’d look like.

This will give you the days count for Z.

1 Like


I separate these:

By adding more columns to a DB/Collection, you are just adding more complexity (As you increase the Matrix calculation for a DB) to the call, so it is better to have more collections with less columns that less collections with more columns :slight_smile: .

Either way, you nailed it with your solution :slight_smile: as in this case 2 more columns should not be that impactful from a user perspective.

I’d have to see a side-by-side performance comparison with what you’re saying.

Speaking from a PHP/MySQL background, your way sounds like it would take longer as it’s pulling and calculating from multiple database collections instead of pulling the data from one collection.

How I explained: Get Data from collection 1 > Calculate > Actions

How you’re saying: Get Data from collection 1, Get Data from collection 2 > calculate 1 vs 2 > action.

Do keep in mind that a single ‘parameter’ is a small load while a collection (even with just 1 parameter) is a much larger load.

Edit: I’d like to get another opinion on the performance question. Have a quick sec @Victor ? Just want to pick your brain. Do you think it would be faster to have the 2 number parameters within the same collection or would it be faster to have the 2 number parameters in their own collection as @JL_LJ stated?

Sure, would also be interested in that :slight_smile: , specially in Heavy user apps.

I get Data collection 1 from previous screen, pass to the next screen, call Data collection 2 in current screen and then only calculations in the custom actions, no input fields in this case.

Do keep in mind that a single ‘parameter’ is a small load while a collection (even with just 1 parameter) is a much larger load.

I just use a normalization approach (So not just related to performance itself), and since my concept does not need to use “JOINS”, but even here, if you have all related with primary key, only impact would be a platform with millions of users or poor performance server, I am not overloading the collections, I pull data in one screen and then another in another screen, I am not merging or putting data together from 2 different Tables (Assuming Adalo treats collections as Tables and not Databases).

Also from point of view of scalability/flexibility, normalization is the way to go (Just my 2 cent opinion)

P.S- Also speak from a SQL background :slight_smile:

But would be great to see some apps and some tests and maybe discuss this in another thread (Not to hijack this one :slight_smile: )

I’d like to see how you’d set that up so that I can understand your solution better.

What input fields are you referring to? There are no input fields in my solution. The form that creates a new Period is required when the user adds a Period record to the collection.

My way doesn’t have to call any data apart from the initial passing of the information from the list button to the Create a new period form. The data is already on-screen and no additional data needs to be pulled in. Just 2 calculations with data that’s already on-screen.

If you’re down, I’d like to see your tutorial still. I’ll make one if you do :sunglasses:
Then, perhaps we can side-by-side test the apps with some data and get really down to the nitty-gritty.

Edit: @JL_LJ I agree that this discussion needs a separate thread. Apologies to @Joyce if this appears to be off-topic or lengthy but both of our intentions are to help you find the best solution for your specific use case. We can chat about this 1-on-1 a little bit and then provide the users with a post explaining the solutions and which is more viable in certain scenarios.

1 Like

Actually my bad, I saw this as input (But this is actually a necessary field, so disregard my comment)

Pardon a man without his morning coffee :smiley: .

Haha love the nitty-gritty, definitely would be great to see if we notice performance differences. I will try to make some time then to make the tutorial.

1 Like

Sorry Sir, I’ve done 2 steps below and still can’t figure out “x” :stuck_out_tongue_winking_eye: