Fixing the Popup UI Issue Sep 28 2025

My app is already live on the App Store, and my main focus now is improving the user experience and fixing some bugs. One issue had been bothering me for a long time: when I added many elements to a page, scrolling up and down became inevitable. But whenever I opened a popup in this state, the entire page would still scroll, which looked really awkward.

I once tried disabling scrolling in JavaScript when the popup was open. It worked, but then the popup itself couldn't scroll either. After consulting AI, I finally learned that this was happening because all of my pages were injected into the index using Shadow DOM. The only feasible solution was to place the popup in the main document instead of inside the Shadow DOM.

That sounded simple, but it turned out to be a huge task. I had to migrate CSS styles into JavaScript and also refactor parts of the JavaScript architecture. Still, I wasn't afraid—because I had AI. With its help, the changes were completed quickly. A few bugs did show up along the way, but once I pointed them out, AI helped me fix them just as fast.

Adding Photo Upload Feature Sep 28 2025

My team suggested adding a photo upload feature to my app, allowing users to submit images such as bleeding spots or medical cases. Initially, I was hesitant due to concerns about limited server storage. However, after checking, I found that only 15% of the 40GB disk space was used, so I decided to implement it.

The main challenge was how to store these images. Although MySQL supports storing images, my data is primarily stored in JSON files, making direct storage cumbersome. I came up with a solution: encode the images in Base64 and include them as part of the JSON data. On the frontend, the images are displayed using HTML <img> tags.

This approach introduces another issue: Base64-encoded images are roughly 33% larger than regular binary images, which could create transmission problems if the JSON file becomes too large. To address this, I implemented a size limit of 5MB per JSON file in JavaScript, triggering an error if exceeded, and compress each image to around 500KB. This effectively prevents overly large JSON files.

Additionally, I integrated Capacitor's camera plugin, allowing the app to directly access the device camera. Finally, I implemented the Base64 decoding logic on the main pages, completing the photo upload and display functionality.

Adding Calendar Feature for Symptom Visualization Sep 30 2025

After some optimization and interface improvements, I needed to implement a new feature. I wanted to create a calendar interface that would allow users to visually see their symptom patterns throughout the month using different colors. The biggest challenge was how to store symptom data and retrieve it efficiently for the calendar page.

Initially, I considered using the large JSON files that were saved and uploaded from the metric page. However, I discovered that these files were too large, especially when they contained photo information, making calendar page retrieval extremely slow.

I came up with a solution: when saving metric data, I would also add a separate table to the database with a similar structure, but in the JSON file I would only store numeric codes representing symptom conditions. For example, 0 represents no symptoms, 1 = cutaneous purpura, 2 = articular purpura.

The database structure I implemented:

CREATE TABLE IF NOT EXISTS symptom_files (
    id VARCHAR(64) PRIMARY KEY,           -- Unique identifier
    user_id VARCHAR(128) NULL,            -- User ID
    username VARCHAR(128) NULL,            -- Username
    file_name VARCHAR(255) NOT NULL,      -- File name
    content LONGTEXT NOT NULL,            -- JSON content (main data)
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,  -- Creation time
    INDEX idx_user_id (user_id),          -- User ID index
    INDEX idx_username (username),        -- Username index
    INDEX idx_created_at (created_at)      -- Creation time index
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

The JSON structure stored in the content field:

{
  "exportInfo": {
    "exportTime": "2024-01-15 14:30:25",
    "recordTime": "2024-01-15 14:30",
    "version": "1.0",
    "appName": "紫癜精灵",
    "dataType": "symptom_tracking"
  },
  "symptomData": {
    "symptoms": [1, 2, 3]  // Array of numeric codes
  }
}

In the calendar page, by reading data using user ID and month, users can understand their symptom patterns for that month, and display them with different colors on the calendar. This approach significantly improved performance while maintaining data integrity and providing users with an intuitive way to track their health patterns over time.

Optimizing Photo Storage Performance Oct 1 2025

I discovered that the previous method of storing images through Base64 encoding had serious performance issues. Every time data was read, these massive image files had to be downloaded, causing extremely slow application response times. After careful consideration, I decided to use the file system to store images, saving only the image access links in the database. Taking the diet page as an example, the optimized JSON data structure is as follows:

{
  "exportInfo": {
    "exportTime": "2024-01-15 14:30:25",
    "recordTime": "2024-01-15 12:30:00",
    "version": "1.0",
    "appName": "紫癜精灵",
    "dataType": "diet_record"
  },
  "dietData": {
    "meal_1": {
      "time": "12:30",
      "food": "米饭、青菜、鸡肉",
      "mealId": 1,
      "images": ["https://app.zdelf.cn/uploads/diet_image_123.jpg"],
      "date": "2024-01-15",
      "timestamp": "2024-01-15 12:30:00"
    },
    "meal_2": {
      "time": "18:00",
      "food": "面条、蔬菜汤",
      "mealId": 2,
      "images": [],
      "date": "2024-01-15",
      "timestamp": "2024-01-15 18:00:00"
    }
  }
}

The images field now stores URLs to access the images instead of Base64-encoded data. This approach dramatically increased the speed of reading the database, as the application no longer needs to download large image files every time data is accessed. Images are now loaded on-demand, significantly improving the user experience.

Fixing Time Zone Issues Oct 2 2025

I also discovered another critical issue: the time was consistently inaccurate. After consulting with AI, I learned that the application wasn't using China's timezone. To ensure time accuracy, I implemented a solution using Capacitor's geolocation plugin to read the user's location and determine the timezone based on their geographical position.

Here's the code for obtaining the user's location:

async _getUserLocation() {
    return new Promise((resolve, reject) => {
        navigator.geolocation.getCurrentPosition(
            (position) => {
                const location = {
                    latitude: position.coords.latitude,
                    longitude: position.coords.longitude,
                    accuracy: position.coords.accuracy
                };
                resolve(location);
            },
            (error) => {
                console.warn('⚠️ 无法获取用户位置:', error.message);
                resolve(null);
            },
            {
                enableHighAccuracy: true,
                timeout: 10000,
                maximumAge: 300000 // 5分钟缓存
            }
        );
    });
}

I then created a mapping table to determine the timezone based on the user's location:

const timezoneMap = {
    '-12': 'Pacific/Kwajalein',
    '-11': 'Pacific/Midway',
    // ... other timezones
    '8': 'Asia/Shanghai',  // China timezone
    '9': 'Asia/Tokyo',
    // ...
};

This approach effectively resolved the time accuracy issues by automatically detecting the user's timezone and applying the correct time calculations throughout the application. The timezone detection ensures that all timestamps are accurate and consistent with the user's local time.

Fixing Notification Functionality Issues Oct 4 2025

Recently, my companion has been constantly reporting issues with the notification functionality. Every time she enters the app, she experiences a bombardment of messages, even when the current time doesn't fall within any scheduled notification time. I've attempted to fix this problem multiple times, but I kept asking AI to figure out the cause on its own. Each time after an update, the problem remained unresolved.

I tried to reproduce this issue by AI but was unsuccessful. However, during one conversation when my companion was sending me messages, she revealed a crucial detail: this bug only occurs when reminder items are set to repeat, and it only manifests after several days have passed. This made me realize that the system might be sending messages, but since the app wasn't running, the app thinks the messages haven't been successfully sent. The moment the app opens, it discovers a large number of unsent messages and sends them all at once, regardless of the current time.

I thought about it and realized that solving this problem shouldn't be too difficult - I just need to delete outdated messages during the app initialization phase. Here's the code I implemented:

function catchUpOverdueReminders() {
  // When entering/resuming the page, perform "silent alignment" for overdue reminders:
  // - Don't send notifications
  // - Only advance to the next scheduled time or delete one-time reminders
  try {
    const now = new Date();
    const toDelete = [];

    reminders.forEach((reminder) => {
      if (!(reminder && reminder.dailyCount > 0 && Array.isArray(reminder.dailyTimes) && reminder.dailyTimes.length > 0)) return;

      // If past the end date, delete directly
      if (isReminderExpired(reminder, now)) {
        toDelete.push(reminder.id);
        return;
      }

      // One-time (non-repeating): if no remaining time points today, delete; otherwise advance to next time today
      if (!reminder.repeatInterval || reminder.repeatInterval === 'none') {
        const nextToday = getNextTimeToday(reminder, now);
        if (nextToday) {
          scheduleUiAdvance(reminder.id, nextToday);
        } else {
          toDelete.push(reminder.id);
        }
        return;
      }

      // Repeating: calculate the next trigger time from the current moment
      const baseDateStr = (() => {
        const y = now.getFullYear();
        const m = String(now.getMonth() + 1).padStart(2, '0');
        const d = String(now.getDate()).padStart(2, '0');
        return `${y}-${m}-${d}`;
      })();
      const nextAt = computeNextTime(reminder, new Date(`${baseDateStr}T00:00:00`), now);

      // If the next time exceeds the end date, delete; otherwise advance UI to nextAt
      if (!nextAt || isReminderExpired(reminder, nextAt)) {
        toDelete.push(reminder.id);
      } else {
        scheduleUiAdvance(reminder.id, nextAt);
      }
    });

    toDelete.forEach((rid) => { try { hardDeleteReminder(rid); } catch (_) { } });
    if (currentRoot) renderReminders(currentRoot);
    console.log('⏰ Aligned overdue reminders (silent advance/cleanup).');
  } catch (e) {
    console.warn('⏰ Failed to align overdue reminders:', e);
  }
}

As expected, the problem was successfully fixed. After resolving this issue, I realized that while AI is powerful, it still cannot replace humans at this stage. Some problems still require human intervention to solve.

I also discovered another issue: if users set up recurring message sending, the app only calculates the next sending time after opening the app following a completed message send. My solution was to schedule multiple notifications in the system immediately when users set up recurring notifications, and then update the status when they enter the app. Here's the code:

function enumerateUpcomingOccurrences(reminder, fromTime, maxDays, perReminderCap) {
  const occurrences = [];
  if (!(reminder && reminder.dailyCount > 0 && Array.isArray(reminder.dailyTimes) && reminder.dailyTimes.length > 0)) return occurrences;
  const enabledTimes = [...reminder.dailyTimes].filter(Boolean).filter(t => isTimeEnabled(reminder, t)).sort();
  if (enabledTimes.length === 0) return occurrences;

  const now = new Date(fromTime);
  const startBoundary = reminder.startDate ? new Date(`${reminder.startDate}T00:00:00`) : null;
  const endBoundary = reminder.endDate ? new Date(`${reminder.endDate}T23:59:59`) : null;

  for (let dayOffset = 0; dayOffset < maxDays; dayOffset++) {
    const day = new Date(now);
    day.setHours(0, 0, 0, 0);
    day.setDate(day.getDate() + dayOffset);
    if (startBoundary && day < startBoundary) continue;
    if (endBoundary && day > endBoundary) break;

    const ymd = formatDateYMD(day);
    for (const t of enabledTimes) {
      const at = new Date(`${ymd}T${t}:00`);
      if (at <= now) continue; // Skip past moments
      if (endBoundary && at > endBoundary) continue;
      occurrences.push(at);
      if (occurrences.length >= perReminderCap) return occurrences;
    }
  }
  return occurrences;
}

With these changes, the notification functionality should now be complete and working properly.

Improving Icon Accessibility Oct 6 2025

I also discovered another issue: the icons in my app were using Google's Material Design icons, which cannot be loaded if users are in China without using a VPN. I replaced these icons with Ionic icons, which can automatically adjust based on whether the user is on iOS or Android, and can be accessed directly in China.

This change significantly improved the user experience for Chinese users, ensuring that all icons display correctly regardless of network restrictions. The Ionic icon system also provides better platform-specific iconography, making the app feel more native to each operating system.

AI Reading Database and Analyzing User Behavior Oct 7 2025

I developed an AI assistant in my app, but currently it cannot analyze user-submitted data. To differentiate my AI assistant from ordinary web chatbots, I plan to enable it to read user-submitted health-related data, analyze the user's physical condition, and provide recommendations.

Initially, my idea was to have the frontend read data from the database and then send it to the AI backend for processing. However, after careful consideration, I realized this approach was very inefficient—since both the backend and database run on the same server, there's no need for the frontend to participate in data transmission and waste additional bandwidth.

So I adjusted the architecture: the frontend only sends basic user information (such as userid and username) to the backend; after receiving this information, the backend queries the user's diet, health, and medical record data from the database, integrates it, and then sends it to the large language model for analysis.

To save on Token costs, I added an "Enable Data Analysis" button on the frontend. The AI only reads and analyzes user data when users actively enable the analysis feature; if not enabled, the AI behaves like a regular chat mode.

After completing the functionality, I began testing but encountered a strange problem: in data analysis mode, whenever I switched pages after a chat ended, the chat history would disappear, and the "AI Data Analysis" button would automatically become inactive. However, strangely, even under these circumstances, the AI could still access my health data.

At first, I thought it was a backend bug—perhaps the analysis logic was still being executed even when the analysis feature wasn't activated. But after checking the code, I found this wasn't the case. It wasn't until one time when the AI's response mentioned: "Based on our previous chat content, your health data is..." that I realized what the problem was.

It turned out that even though the frontend state was reset after switching pages, it was still part of the same session. The AI's responses continued to be based on previous context for reasoning. To completely solve this problem, I made the AI page create a new sessionID every time it initializes, ensuring that each conversation is independent and no longer affected by previous chat content.

App Version and Update Check Oct 13 2025

I have completed the functionality for the square page, but I suddenly realized an issue: since my app is not published on any Android app store, how can Android users know if their app is the latest version?

My solution is to add a JSON file on the app's website that includes update information for each version. The current JSON file looks like this:

{
  "app_name": "紫癜精灵",
  "package_name": "com.junxibao.healthapp",
  "versions": [
    {
      "version": "1.2.5.2",
      "release_date": "2025-10-9",
      "changes": [
        "Fixed an issue when users cropped their avatars"
      ]
    },
    {
      "version": "1.3.0.0",
      "release_date": "2025-10-11",
      "changes": [
        "Added square page functionality",
        "Added automatic update check feature"
      ]
    }
  ]
}

In the app, I only need to add a version number and compare the local version with the remote version from the JSON file. If the local version is older than the remote version, the app will display the update prompt along with detailed information for each version.

Thus, for future updates, I only need to update the app's local version number and modify the server JSON file. The app will then automatically check for updates without relying on any app store.

ICP Filing Challenge Oct 19 2025

One morning after waking up, my companion told me that users were reporting they couldn't find our app on the App Store. At first, I thought the users had misspelled the name and didn't pay much attention. But upon closer investigation, I discovered that the app was indeed no longer searchable on the Chinese mainland App Store. My first reaction was: could this be a bug on Apple's end? Logically, if an app gets delisted, Apple should send notifications or email reminders, but I hadn't received any messages.

When I continued checking the App Store Connect settings, I noticed a prompt in the "Countries and Regions" section—the Chinese mainland region was not ICP filed. That's when I realized the problem might be related to filing. So I immediately set out to apply for ICP filing for the app.

The entire filing process wasn't particularly complex since we already had servers and domain names. However, after submitting the materials, we were quickly rejected by Alibaba Cloud's initial review. There were two reasons:

• The reviewer believed my app was company-based and required filing under a company name, not as an individual;
• The system incorrectly identified information from my ID card, showing "incorrect filer identity information."

Additionally, the reviewer specifically emphasized over the phone that the app must not contain any medical-related content. I could solve the first two problems, but this last requirement left me in a difficult position—after all, our app was specifically designed to serve patients. At that moment, I felt very frustrated and even considered giving up on filing, letting users continue with the beta version, or spending 1,000 yuan to hire Alibaba Cloud's "expert service" to handle it for me.

However, holding onto a glimmer of hope, I resubmitted the application. This time, I barely changed anything, just adding a note in the remarks: "This is a personal developer's app that does not contain any medical advice."

Unexpectedly, this time it was approved smoothly!

At this point, our app could finally be relisted on the Chinese mainland App Store.

Completing Auto Message Update Check Oct 31 2025

My teammate suggested adding an automatic "message update check" to the app—whenever someone comments on or replies to a user's post, the system should promptly notify that user.

After researching, I found there wasn't a straightforward plugin in framework Capacitor to handle remote push. iOS requires APNs and Android relies on Firebase—this is a bit heavy for my current stage.

So I chose a pragmatic interim approach: instead of push notifications, I implemented an in-app "Message Center" where users can see all messages relevant to them. The system also shows how many new items have appeared since their last visit.

The first part was simple—iterate the database for items related to the current user and sort them by time. The second part took a little thought. Later that night, I realized I could store the user's last-view time in localStorage, and when loading messages, count how many relevant records in the database have timestamps later than that value. That gives me the exact number of new messages.

Once the approach was clear, implementation went smoothly and the feature was quickly completed.

A Painful Lesson in Data Loss Nov 21 2025

A long time ago, I renamed my GitHub repository. Recently, for security reasons, I planned to set the repository to private—worried that exposing the source code publicly might lead to someone attacking my server. But here's the problem: once set to private, my server would no longer be able to pull code from GitHub, and since GitHub is mostly blocked by the GFW in China, I also couldn't log into the same account on the server.

In desperation, I tried using various GitHub mirror sites, but still couldn't complete account login. Eventually, I had no choice but to compromise: I set the repository back to public and planned to use the githubfast mirror to pull remote code on the server.

However, during the switching process, I accidentally wrote the wrong GitHub repository address on the server. When running git pull, the system prompted that the local version and remote version were inconsistent, but I didn't think much of it at the time and directly force-pulled the remote code, which resulted in the local project folder being corrupted. Actually, at this point, the problem wasn't so severe that it couldn't be recovered.

What really made things irreversible was that I impulsively used rm -rf to delete the entire folder! If I had immediately used file recovery tools after this step, I might still have been able to recover the data. But I had another moment of impulsiveness and immediately pulled the correct project files from GitHub.

Since user data and code were stored in the same folder, and this data wasn't tracked by Git, this data was almost impossible to recover.

This incident taught me a very profound lesson. Afterward, I seriously reflected and decided that from now on, I must regularly back up the server to avoid similar tragedies from happening again.

Completing the Check-in System Dec 1 2025

Recently, I discovered a problem with my health tracking app: the user engagement rate is quite low. To be honest, not many people open it daily or record their lives. So I started thinking—how can I make users want to come back every day?

Around this time, I was using Duolingo to learn Spanish, and I suddenly realized: why can I stick with it every day?

It's simple—it's because of their "streak" system. Every day I see that consecutive day number go up, and there are little animations every day. I really want to keep going and not break the streak.

So I thought: why can't my own app have one too?

So I started working on it. I added two fields to the users data table:

• Current consecutive days
• Highest consecutive days

Then in the backend's getjson router, every time the frontend uploads data, I check:

• "Is this the user's first upload today?"
• "Should I update the streak count?"
• "Should I refresh the maximum record?"

Of course, I also display these two numbers directly on the "My" page, so users can see their progress day by day as they keep going.

What really got me excited was—I also created a celebration animation system!

I referenced Duolingo's style:

• 1–5 consecutive days: light animation
• Gradually intensifies after that
• Every full week: confetti
• Every 100 days: a big explosion (really satisfying!)

However, I did hit a snag in the middle. At first, the celebration animation wouldn't trigger at all, and I was almost ready to give up. Finally, with AI's help, I discovered—I had written the flow backwards.

My original approach was: update database first → then check if it's the first upload today

Of course, the check result would always be "you've already checked in today," so the animation would never show.

Later, I changed the order to: check first → then update database

It worked instantly. The animation triggered smoothly, and the whole experience came alive.

Now that the entire feature is working, I feel the app finally has a "persistence vibe" to it, and it feels more like a real companion that accompanies users in their daily lives. If it can make users want to open it and check in every day, just like Duolingo, then I think this feature is a success.

System Dark/Light Mode Toggle Dec 7 2025

Actually, I've wanted to implement a theme switching feature in my app for a long time, allowing users to quickly switch between dark mode, light mode, or follow the system settings. I thought it would be simple—after all, my CSS already uses @media queries for dark/light mode logic, so I could just call that directly, right?

But when I actually tried to implement it, I discovered that to achieve independent theme switching within the app, you actually need to rely on "forced theme overrides" in CSS. In other words, you have to write your own logic to forcibly switch all element colors. This process was really too difficult for me as a frontend beginner. I tried several times, and each attempt ended in failure. Even with AI's help, it didn't work—either the entire color scheme got messed up, or some components couldn't properly adapt to the theme.

After struggling for a while, I suddenly thought of an approach: since the difficulty lies in forcibly overriding colors, why not let the app's native layer directly switch dark mode? As long as the native layer switches the theme, the elements in my app will naturally follow the dark mode logic I wrote in @media queries—problem solved!

I searched through Capacitor plugins but couldn't find one that worked directly, so I decided to write my own plugin. The iOS side went very smoothly—I just bridged the UIWindow.overrideUserInterfaceStyle API, and the theme switching was perfectly implemented.

But when I got to the Android side, I discovered there was no corresponding API to call. I tried many approaches, but they all failed. I had no choice but to compromise:

In the settings, I only show the dark/light mode toggle for iOS. Android and web versions don't display this option.

Checking User Streak Days Dec 11 2025

When implementing the user streak day counting feature, the key challenge was how to reliably determine whether a user had completed their check-in on the previous day. Initially, my approach was to have the frontend initiate a request when users opened the app's homepage (index page) to check if they had checked in yesterday; if not, the backend interface would reset current_streak to 0.

However, this approach exposed several reliability issues in practice: First, the determination logic depended on when users launched the app. If a network interruption occurred at the moment of launch, the check would be skipped. Second, if users didn't open the app for a long time, the server would have no way of knowing that the user had broken their streak, causing the streak count to fail to reset in time, which affected the accuracy of features like leaderboards that depend on real-time data.

Based on these limitations, I decided to migrate the "streak break determination" from the client side to the server side, with the server executing a unified check task at 0:00 every day: the system would iterate through all users, determine whether they had submitted check-in records the previous day, and if not, set that user's current_streak to 0. To implement this mechanism, I used APScheduler as the scheduled task scheduling framework (pip install APScheduler) and improved the database operation logic.

At the same time, since the production environment uses Gunicorn to deploy the backend, to avoid multiple workers triggering scheduled tasks simultaneously and causing duplicate execution, I introduced a file lock mechanism in the task execution flow to ensure that scheduled tasks are executed by only one process at any given moment, thereby guaranteeing data consistency and thread safety.

Core code:

def _check_user_has_submission_for_date(user_id, target_date, conn):
    cursor = conn.cursor()
    try:
        for table in RECORD_TABLES:  # ['metrics_files', 'diet_files', 'case_files', 'symptom_files']
            try:
                query = f"""
                    SELECT COUNT(*) as count
                    FROM {table}
                    WHERE user_id = %s AND DATE(created_at) = %s
                    LIMIT 1
                """
                cursor.execute(query, (user_id, target_date))
                row = cursor.fetchone()
                if row and row[0] > 0:
                    return True
            except mysql_errors.ProgrammingError as e:
                if e.errno == 1146:  # Table doesn't exist
                    continue
                else:
                    raise
            except Exception as e:
                logger.warning("Error checking %s for user %s on %s: %s", table, user_id, target_date, e)
                continue
        return False
    finally:
        try:
            cursor.close()
        except Exception:
            pass

Now my app's check-in system should be able to operate perfectly.

The process of making the app is not over yet, I will continue to update this passage, thank you. Because this post is already quite long, I will open a separate page for the next post. You can click here to view the next article.