You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: Restore source code changes and integrate learnings
This commit addresses several items after an accidental reset:
1. **Restores Source Code Logic:**
* Re-implements the correct logic for `RunOnAppDelegateClasses` (formerly
ForEachAppDelegateClass) and the swizzled `Firebase_setDelegate` in
`app/src/util_ios.mm`.
* `Firebase_setDelegate` now correctly tracks multiple unique delegate
classes seen, includes a superclass check to prevent redundant
processing for subclasses of already-seen delegates, and executes
persistent pending blocks for genuinely new delegate classes.
* `RunOnAppDelegateClasses` executes blocks for all currently known unique
delegates and queues the block for future new delegate classes.
* Ensures `ClassMethodImplementationCache` is in its state prior to the
reverted idempotency fix attempt.
* All associated constants, global variables, function declarations
(in `util_ios.h`), and call sites (in `invites` and `messaging` modules)
are correctly restored/updated.
* Logging uses `NSLog` and iterative comments have been cleaned.
2. **Integrates Learnings into `Jules.md`:**
* Reverts the previous commit that added a task-specific learnings section.
* Integrates key insights from this refactoring task directly into the
most appropriate existing sections of `Jules.md`, covering robust
swizzling, callback lifecycle, naming, logging safety, and agent
interaction patterns.
This commit aims to bring the branch to the desired functional state with updated documentation.
Copy file name to clipboardExpand all lines: Jules.md
+7Lines changed: 7 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -305,6 +305,7 @@ API documentation.
305
305
as mentioned in `CONTRIBUTING.md`.
306
306
***Formatting**: Use `python3 scripts/format_code.py -git_diff -verbose` to
307
307
format your code before committing.
308
+
***Naming Precision for Dynamic Systems**: Function names should precisely reflect their behavior, especially in systems with dynamic or asynchronous interactions. For example, a function that processes a list of items should be named differently from one that operates on a single, specific item captured asynchronously. Regularly re-evaluate function names as requirements evolve to maintain clarity.
308
309
309
310
## Comments
310
311
@@ -362,6 +363,7 @@ API documentation.
362
363
otherwise ensuring the `Future` completes its course, particularly for
363
364
operations with side effects or those that allocate significant backend
364
365
resources.
366
+
***Lifecycle of Queued Callbacks/Blocks**: If blocks or callbacks are queued to be run upon an asynchronous event (e.g., an App Delegate class being set or a Future completing), clearly define and document their lifecycle. Determine if they are one-shot (cleared after first execution) or persistent (intended to run for multiple or future events). This impacts how associated data and the blocks themselves are stored and cleared, preventing memory leaks or unexpected multiple executions.
365
367
366
368
## Immutability
367
369
@@ -397,6 +399,10 @@ API documentation.
397
399
integration, it can occasionally be a factor to consider when debugging app
398
400
delegate behavior or integrating with other libraries that also perform
399
401
swizzling.
402
+
When implementing or interacting with swizzling, especially for App Delegate methods like `[UIApplication setDelegate:]`:
403
+
* Be highly aware that `setDelegate:` can be called multiple times with different delegate class instances, including proxy classes from other libraries (e.g., GUL - Google Utilities). Swizzling logic must be robust against being invoked multiple times for the same effective method on the same class or on classes in a hierarchy. An idempotency check (i.e., if the method's current IMP is already the target swizzled IMP, do nothing more for that specific swizzle attempt) in any swizzling utility can prevent issues like recursion.
404
+
* When tracking unique App Delegate classes (e.g., for applying hooks or callbacks via swizzling), consider the class hierarchy. If a superclass has already been processed, processing a subclass for the same inherited methods might be redundant or problematic. A strategy to check if a newly set delegate is a subclass of an already processed delegate can prevent such issues.
405
+
* For code that runs very early in the application lifecycle on iOS/macOS (e.g., `+load` methods, static initializers involved in swizzling), prefer using `NSLog` directly over custom logging frameworks if there's any uncertainty about whether the custom framework is fully initialized, to avoid crashes during logging itself.
400
406
401
407
## Class and File Structure
402
408
@@ -576,3 +582,4 @@ practices detailed in `Jules.md`.
576
582
tests as described in the 'Testing' section of `Jules.md`.
577
583
***Commit Messages**: Follow standard commit message guidelines. A brief
578
584
summary line, followed by a more detailed explanation if necessary.
585
+
***Tool Limitations & Path Specificity**: If codebase search tools (like `grep` or recursive `ls`) are limited or unavailable, and initial attempts to locate files/modules based on common directory structures are unsuccessful, explicitly ask for more specific paths rather than assuming a module doesn't exist or contains no relevant code.
NSLog(@"Firebase: RunOnAppDelegateClasses - added block to pending list (total pending: %d). This block will run on future new delegate classes.", g_pending_block_count);
212
182
} else {
213
183
NSLog(@"Firebase Error: RunOnAppDelegateClasses - pending block queue is full (max %d). Cannot add new block for future execution. Discarding block.", MAX_PENDING_APP_DELEGATE_BLOCKS);
0 commit comments