המשך המסע בין ספריות הפיתוח לאנדרואיד

OkHttp ,Picasso ו-ActiveAndroid הן עוד ספריות שיכולות לעזור לכם לא מעט בפיתוח האפליקציה שלכם

גלעד חיימוב, מומחה לפיתוח מערכות אנדרואיד וצד-שרת

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

הפעם אני ממשיך עם OkHttp. זוהי הדרך שבה Android's HttpClient הייתה צריכה להיכתב: מאוד פשוט ומאוד חכם. ספריית OkHttp דואגת באופן פנימי ללולאת ניסיון חוזר (Retry loop), דחיסה אוטומטית של מטען ייעודי (Payload auto compression), תמיכת Http/2, איגום חיבור (Connection pooling) ומטמון תגובה, כך שתוכלו להימנע מגישת רשת שאינה הכרחית.

השימוש ב-OkHttp הוא פשוט לאין ערוך מאשר בשפות אחרות.

Http POST:

Http GET:


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

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

Picasso: גם גוגל משתמשת בה – ומסיבות טובות

Picasso היא הדרך הפשוטה והיציבה ביותר לניהול הורדה, שמירה במטמון, התאמת גודל וחיתוך של תמונה.

ההצהרה שלהלן:


תבצע עבורכם זאת:
•    תתחבר ל-URL מרוחק.
•    תוריד תמונה.
•    תאחסן אותה במטמון URL מיוחד (Local Cache) ותנהל אותו עבורכם.
•    תשנה את גודל התמונה המקורית לפני הורדתה לזיכרון.
•    תריץ את כל הנ"ל על מאגר נימים (Thread Pool), שמנוהל בידי Picasso.
•    תשתמש בתמונה שגודלה שונה על מנת לאכלס את ה-ImageView שלכם.
•    ובנוסף – כמה מועיל – לפני כל גישה עתידית מהאפליקציה לתמונה, היא תיגש למטמון המקומי ותנסה לטעון את התמונה ממנו ובכך לחסוך תעבורת רשת.

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

במכשיר האנדרואיד הממוצע, אפליקציה אינה מקבלת יותר מ-50-60 מגה-בייטים של זיכרון RAM ופקטור הפיקסלים לבייט (Pixel to Byte Factor) עבור רוב מכשירי האנדרואיד הוא 4. משמעות הדבר היא שניסיון לטעון תמונה בגודל 13 מגה פיקסל מכרטיס ה-SD ידרוש 52 מגה-בייט של RAM. במילים אחרות, האפליקציה שלכם תקרוס באופן מיידי.

זוהי רק דוגמה אחת לחוזק של Picasso. אחד הדברים הראשונים שאני עושה בעבודת אופטימיזציה או דיבוג של פרויקט Media intensive legacy הוא לשנות את כל טעינות התמונות ל-Picasso. אתם תופתעו מההשפעה שיש לצעד הזה בלבד על איכות האפליקציה.

אחת מהעדויות החזקות ביותר לכוחה של הספרייה הזו היא שדגימות קוד רבות של אנדרואיד מהשנתיים האחרונות ששייכות לגוגל (Google) משתמשות ב-Picasso לטעינת תמונות.

ActiveAndroid: מיפוי אובייקט או בסיס נתונים

ORM זה קיצור של Object-Relational Mapping (בעברית: מיפוי אובייקטי-רלציוני). ה-ORM הפך פופולרי בימי J2EE. הוא מאפשר אחסון של ה-POJO-ים שלכם וקבלתם מבסיס נתונים, ללא צורך להמירם לשדות נפרדים.

האם הוא עוזר? מאוד, שכן הוא מאפשר לכם לכתוב חלק גדול מהאפליקציה שלכם ללא כתיבה כלל של הצהרת SQL.

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

איך משתמשים בפלטפורמות האלה?

ראשית, אתחלו באובייקט אפליקציה על ידי הרחבת מחלקת אפליקציה מותאמת.


שנית, צרו POJO עבור מחלקת מודל, עם מחלקות עבור כל אחת מהרשומות שבכוונתכם לאחסן במאגר הנתונים. כל POJO כזה יכול לשכון ב-Table משלו. יש להשתמש באנוטציות (הערות הסבר) על מנת לפרט את שמות שדות ה-DB עבור כל אחד מהחברים המאוחסנים.

במידה שאתם מעוניינים לקבוע מדד עבור חבר, השתמשו בתיוג (Annotation) זה:

בנוסף, בכדי למנוע מהספרייה מלסרוק את כל הקלאסים שבאפליקציה – התנהגות ברירת המחדל שלה – מומלץ בחום לפרט את כל מחלקות המודל שלכם בסעיף ההצהרה הבא:

שימו לב: מחלקות מודל שאינן מופיעות ברשימה זו לא יזוהו על ידי ActiveAndroid.

זוהי שורת קוד לכתיבה לבסיס הנתונים:

במידה שיש צורך בכתיבות מרובות, דרך יעילה יותר תהיה לקבץ אותן לפעולה אחת – כך:

חמישית, יש לבצע קריאה של ה-POJO-ים מבסיס הנתונים:

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

הטור הבא יעסוק ב-LibStreaming – הדרך הפשוטה לבצע הזרמת וידיאו, וב-LeakCanary, שמאפשרת גילוי זליגות זיכרון (Memory leaks) בשורת קוד אחת.

הכותב הינו מפתח אנדרואיד עצמאי ומנכ"ל Mobile edge software solutions.

תגובות

(7)

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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

  1. Netanel Sananes

    WOW! Very informative and innovative. .Especially the part about the Object Relational Mapping. .I do invigorating to start using this method and leave the SQL declarations behind

  2. מרקל אדי

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

  3. גלעד

    Dimma - performance is always an issue, but modern ORM platforms, and ActivieAndroid is definitely such, do great job in bringing ORM performance to that of hand-coded SQL My own tests show that when it comes to single-record operations, namely read/write of a single object - there is no effective difference between SQL and ORM However, there is a major difference in performance when it comes to multi object retrieval using smart filters, inner/outer joins etc. As a rule of thumb I will always prefer ORM for _most_ aspects of my app's DB interaction up to the point of a mission critical complex SQL query in which case I will hand code the retrieval logic

  4. אורן מנשה

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

  5. Dimmap

    Thank you Gilad . this is very interesting staff But regarding ORM - from my own experience it might have a significant impact on the application performance Is there an Android ORM tool with no such "cost" in performance? Dimma

אירועים קרובים