Connect4 — תוכנית מימוש ואימות למורה

מפת 13 הפרקים

יעד ומקומות העבודה

היעד הוא אפליקציית Android ב־commit 5387b7dedbc66edb4bc5ad748cbaa32f15b1035b של Connect4. סדר ההוראה נגזר מתלות בין מושגים, ולא מהיסטוריית הפיתוח. המודלים והיריב המתקדם מסופקים; אימון, Python, JAX ו־Colab אינם חלק ממשימות התלמיד.

מי שמיישם או מתקן את המסלול חייב לקודד את המעבר ב־Connect4T, לבנות ולהפעיל אותו, ורק אחר כך לכתוב את ההוראות מן ה־diff. אין לדרוס את פרויקט השלבים בעותק של היישום הסופי. בשיפור עתידי יש לחזור ל־checkpoint המתאים בעותק עבודה מוסכם, ולא להעמיד פנים שהמצב הסופי הוא נקודת ההתחלה של תלמיד בפרק מוקדם.

בעת תחילת העבודה Connect4T היה נקי וב־commit 4102fc70172c49158823a7d2a4a1c60de3548955. לא נוצרו commits חדשים ולא שונה ה־index. View Binding היה פעיל ב־Gradle; מצב 00 משלים את השימוש בו ב־Activity, כהכנת המורה לפני פרק 1. שינוי baseline המדויק.

רצף ושיטת כתיבה

13 הקבצים, מטרתם ותוצאתם מפורטים ב־מפת המסלול. בכל אחד מופיעים ההסבר, קוד חדש או diff ממוקד, בדיקת תוצאה ושאלת הבנה. פרקים ארוכים יכולים להתפרס על כמה מפגשים; מספר הקבצים אינו מספר שעות ההוראה.

• שומרים Java, XML, View Binding, תשתית Gradle ובדיקות התבנית. אין Kotlin או Compose בקוד האפליקציה.
• משתמשים באותו GameEngine לכל המצבים. GameAction היא עמודה; GameState הוא צילום מנותק. למחשב נותנים צילום ומקבלים פעולה, בלי לתת לו את המנוע החי.
• חבילת המורה בפרק 7 כוללת את MCTS, PolicyValueEvaluator, StateEncoder, TfliteEvaluator, ModelCatalog וכל זוגות המודל/מטא־דאטה. ComputerMoveService וה־Activity מלמדים את החיבור, fallback וביטול.
• הפעולות החדשות ברשת מתווספות בהדרגה: הזדהות, חדרים ותפיסת מושב, מהלך עם קידומת צפויה, ואז חיבור מחדש. לא נותנים הרשאת כתיבת מהלכים בפרק החדרים הראשון.
• API keys/config נמסרים בנפרד; החבילות אינן מכילות google-services.json, סיסמאות, service accounts או כללים חיים של מסד משותף.

Checkpoints וחבילות

• מצבים 00–13: קוד ומשאבים של כל גבול פרק, יחד עם הגדרות הבנייה הרלוונטיות. זו ראיית השוואה למורה, ולא הוראת החלפת פרויקט לתלמיד. אין כאן Gradle wrapper, local.properties או קבצים הנוצרים בבנייה. את קובצי המודל הבינריים לוקחים מחבילת פרק 7 ואת הגרפיקה מחבילת פרק 13.
• בכל פרק יש patch של המעבר המדויק וחבילת הבדיקות ששונו בו. ה־patch כולל גם קוד שסופק למורה; אין בכך דרישה ללמד את הפנימיות שלו.
• חבילת אימות מלאה ותוצאות: בדיקות JVM, בדיקות Android, תצורת debug ל־emulators, בדיקות כללים ופלטי תוצאות.
• snapshots ויומני העבודה המקוריים נשמרו גם ב־C:\Temp\connect4-course-20260921. שינויי האפליקציה נשארו ב־Connect4T, ללא commit.

מצב האימות

כל גבול פרק נבנה ב־Connect4T לפני כתיבת העמוד שלו. בשלבים 01–02 נותרו יומני הבנייה; דוחות XML נפרדים נשמרו מהשלב השלישי ואילך. “עבר” מתייחס לבדיקה המצוינת בלבד, ואינו טענה שכל תצורת מכשיר/חשבון נבדקה.

נוסף על הטבלה:

• כל 8 בדיקות כללי RTDB עברו ב־Firebase emulator, כולל הרשאות, תפיסת מושב מתחרה, תור, קידומת ושימור הרשאות מייצגות של יישומים אחרים.
• שני מכשירי Android נפרדים השלימו את 0011223 דרך פקדי המסך; אחד מהם עבר recreation באמצע. לקוח Firebase שלישי צפה בתוצאה. שתי ריצות התפקידים האחרונות עברו; הן נפרדות מסוויטת המכשיר היחיד.
• בדיקות המודל הריצו LiteRT ובדקו fallback, מטא־דאטה שגויה וביטול. לא בוצע אימון חדש ולא נמדדה כאן מחדש עוצמת המשחק.
• צילום התצוגה הסופית נבדק על emulator. רשימת הבדיקות בכל פרק נשארת גם רשימת קבלה ידנית עבור מכשירי הכיתה.

תיקונים ממוקדים שנמצאו באימות

פרויקט הייחוס נשאר ללא שינוי. ב־Connect4T ובתיעוד נוספו שתי הגנות ביחס אליו:

1. בפרק 10, לאחר join שהתחייב, קוראים את החדר מחדש לפני אימות timestamps ודיווח על התפקיד. זאת בעקבות כשל Android שנמצא עם צילום השלמת transaction.
2. בפרק 13, קריאה חד־פעמית ישנה אינה דורסת עדכון listener חדש יותר של אותו חדר. בדיקת שני מכשירים נכשלה פעם בהמתנה לתוצאה אצל צהוב; נוסף מבחן regression דטרמיניסטי של סדר snapshots והגנה מפני קיצור ההיסטוריה. בדיקת שני המכשירים עברה לאחר התיקון.

תיקוני harness: opt-in לבדיקות Firebase נקרא כמחרוזת ומומר ל־boolean; מפתחות הדמה של לקוחות הבדיקה ייחודיים כדי למנוע שימוש ב־FirebaseApp שכבר נמחק. בדיקת שני המכשירים מוחרגת מסוויטת מכשיר יחיד ומופעלת בנפרד — לא סופרים אותה כבדיקה שעברה כשהיא לא הופעלה.

מה עדיין דורש סביבת כיתה/חשבון אמיתי?

• כניסה אינטראקטיבית עם Google, ביטול הבורר והחלפת חשבונות; כאן נבדקו בנייה ושגיאת תצורה חסרה.
• בדיקת קבלה על Firebase החי עם שני שחקנים וצופה, תחת ההרשאות בפועל. לא נפרסו כללים ולא נוצרו משתמשים/חדרים במסד החי במהלך עבודה זו.
• בחירת גדלי טקסט, מכשירים פיזיים ותרחישי נגישות מעבר לתצוגות שנבדקו. אין לטעון כאן לבדיקת TalkBack מלאה.

הרצת בדיקות המורה

1. התקינו את חבילת האימות בתוך עותק העבודה המתאים. השאירו את test ו־androidTest של התבנית.
2. ב־Terminal של הפרויקט, הריצו gradlew testDebugUnitTest assembleDebug. סביבת האימות השתמשה ב־JBR של Android Studio ובגרסאות Gradle/SDK של הפרויקט, ללא שדרוג אוטומטי.
3. לצורך Firebase, עברו לתיקיית firebase ב־Terminal והפעילו firebase emulators:start --only auth,database --project demo-connect4. אימות הכללים הוא מקומי בלבד.
4. לכל מכשיר בדיקה הפעילו port forwarding. לדוגמה למכשיר הראשון:

adb -s emulator-5554 reverse tcp:9000 tcp:9000
adb -s emulator-5554 reverse tcp:9099 tcp:9099

1. הריצו את בדיקות Android עם -Pandroid.testInstrumentationRunnerArguments.firebaseEmulators=true ו־-Pandroid.testInstrumentationRunnerArguments.notClass=com.example.connect4.CourseCrossDeviceTest לצד connectedDebugAndroidTest.
2. לבדיקות כללים: בתיקיית firebase הריצו npm ci, הגדירו FIREBASE_DATABASE_EMULATOR_HOST=127.0.0.1:9000, ואז npm test. אין להריץ את סוויטת הכללים במקביל לבדיקות Android: היא מנקה את נתוני סביבת הבדיקה בין מקרים.
3. לבדיקת שני מכשירים, התקינו APK ואפליקציית androidTest בשניהם. הפעילו במקביל את CourseCrossDeviceTest באמצעות adb shell am instrument -w, עם crossDevice=true, אותו runId, ותפקיד red במכשיר אחד ו־yellow בשני. הליך זה יוצר חשבונות בדיקה ב־emulator בלבד. הקוד המלא בחבילת האימות.

ל־Connect4 ול־Connect4T אותו application ID. התקנה של אחד מחליפה את האחר במכשיר. באימות השתמשנו ב־emulators ייעודיים, ויש לזהות את הפרויקט שממנו נבנה ה־APK לפני שמסיקים מסקנה מתצוגה או מנתונים שמורים.

בדיקת פרסום ותצוגה

ב־21 בספטמבר 2026 נבנה אתר Jekyll בהצלחה. 15 עמודי המסלול נפתחו בדפדפן, קישורי המסלול נבדקו, וכל חמש השוואות המילים שמרו על לפני משמאל ואחרי מימין, גם בחלון צר. נבדקו חזותית מפת המסלול והצגת הקוד. 154 קטעי קוד ו־diff הושוו באופן עצמאי לתוכן checkpoints לפני ואחרי השינוי; כל ההשוואות עברו.

באפליקציה נבדקו גם מסך אנכי, מסך אופקי ומצב לילה. בדיקה נפרדת ביצעה מהלך, יצאה למסך הבית, עצרה את התהליך והפעילה מחדש: המהלך נשמר והמסך חזר לתור צהוב. קובצי היריב המתקדם והנכסים המסופקים הושוו בינארית למקור ונמצאו זהים.

צילום אנכי · צילום אופקי · מצב לילה