פוסט 6 - אפליקציית המשתמשים (תושבים)

בפוסט הזה אני הולך לדבר על האפליקציה המשמשת את התושבים.

תחילה אתאר מנגנון מעניין המאפשר לרשות מקומית לשלוח הודעות בפוש, בין אם פרסומיות ובין אם אינפורמטיביות על המתרחש בעיר.

המנגנון הזה משלב בעצם את היכולות של שני המנגנונים שהצגתי בפוסט הקודם ואף מתבסס על מידע המגיע ממשתמשי האפליקציה.

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

כעת נשאלת השאלה, כיצד המערכת יודעת לאיזה תושבים לשלוח את ההודעה?

הבה נצפה בתרשים ולאחר מכן אסביר אותו.

פתרון:

אז כפי שניתן להבחין, הפתרון מורכב משני תהליכים:

תהליך 1 - מתאר מה קורה מצד משתמשי האפליקציה.
תהליך 2 - מתאר מה קורה ברגע שמשתמש ממשק הניהול שולח הודעה.

** UUID - מספר מזהה יחודי שהאפליקציה מקבלת לאחר התקנה, והוא קבוע.

וכעת נסביר כל אחד מהם:

התהליך הראשון מתאר את אשר קורה ברגע שנכנסים לאפליקציה, בכל פעם מחדש, נשלחת פייה ל-Notification Micro Service, עם ה-UUID והמיקום הנוכחי של המשתמש. הרישום של המכשיר בשירות ה-Push notification, (השירות שמסופק ע"י  Ionic.io), הוא חד פעמי, ונשמר במערכת כלומר היחס הוא 1:1, UUID:tokenID. תהליך זה לא מצויין בתרשים אבל מתבצעת בדיקה האם כבר קיבלנו את ה-token בעבור ה-UUID שנשלח, במידה וכן לוקחים את ה-token שהתקבל בעבר עובר ה-UUID, (המשמעות היא שהמשתמש כבר רשום בשירות שליחת ההודעות של ionic.io), ושומרים אותו יחד עם פרטי המיקום הנוכחים של המשמתש.

התהליך השני מתאר מה קורה ברגע שמשתמש ממשק הניהול שולח הודעה ממש הניהול.

למעשה ברגע שלוחצים על Send  נשלחת פניית REST ל-Notification Micro Service שמכילה שני פרטים:
* נוסח ההודעה.
* הריבוע הדימיוני שדיברנו עליו בפוסט הקודם שמוגדר ב-Promotion code והמשוייך למשתמש.

ברגע שמתקבלת הפניה ב-Notification Micro Service אנו בודקים איזה מבין המשתמשים הרשומים במערכת נמצאים כעת בריבוע הדימוני שקיבלנו, ושומרים את ה-token שלהם, ברגע שסיימנו לאסוף את כל ה-tokens, אנו שולחים פניה לשירות הודעות הפוש שמסופק ע"י ionic.io עם רשימת ה-tokens ונוסח ההודעה ומכן השירות כבר דואג להעביר את ההודעה למשתמשים ע"י זיהוי סוג המכשיר ע"ב ה-token ופניה בהתאם ל-GCM ו-APNS.

כעת נדבר על ממשק המשתמש באפליקציה:

אירועים

קיימים 14 אירועים מוגדרים מראש שהצלחתי לחשוב עליהם וקיים אירוע נוסף שנקרא "אירוע אחר" המאפשר שליחת אירוע שלא קיים במערכת.

התרשים הבא מדגים את השתלשות האירועים בעת שליחת דיווח:

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

כאשר לוחצים על סוג הדיווח נשלחת פניה ל-Listener Micro Service, המכילה שני פרמטרים:

1. סוג האירוע.

2. מיקום נוכחי.

זאת למעשה הנקודה שבה התרשים מתחיל, כאשר נשלח הדיווח אנו מחכים לתשובה מ-Listener Micro Service.

תשובה שלילית מסיבה כל שהיא -> שליחת האירוע נכשלה, חוזרים למסך הבית

תשובה חיובית  -> קופץ חלון המעדכן האם האירוע זוהה כבר כאירוע אמת או שמא טרם נאספו מספיק דיווחים,

בחלון הקופץ מתבקש התושב המדווח להוסיף תמונה ממקום האירוע. 

במידה ומעוניין יכול לבחור בין שתי אופציות:

1. לעבור למסך המצלמה והצילום שיצלם יעבור אלינו.

2. לבחור תמונה מספריית התמונות.

בין אם בחר לשלוח אלינו תמונה או לאו אנו מקפיצים חלון נוסף שבו מתבקש התושב להוסיף תיאור מילולי על המתחרש.

עקרון חשוב:

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

ניקוד

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

בפוסט הבא אתמקד בנושא מעט אחר והוא שלבי Deployment של המוצר, איך עובד מנגנון ה-Pipe Line בפיתוח, קשור למושגים שדיברנו עליהם CD ו CI, אזכיר טכנולוגיות ומושגים חדשים מעולם ה-DevOps ואגע קצת בעיצוב האפליקציה, דף הנחיתה וממשק הניהול. 

זהו לעת עתה,

מייק.