ממשקי API של Android 3.2

רמת ה-API: 13

Android 3.2 (HONEYCOMB_MR2) היא גרסה מצטברת של הפלטפורמה שמוסיפה יכולות חדשות למשתמשים ולמפתחים. בקטעים הבאים מפורטת סקירה כללית על התכונות החדשות ועל ממשקי ה-API למפתחים.

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

רגעי השיא של הפלטפורמה

תכונות חדשות למשתמשים

• אופטימיזציות למגוון רחב יותר של טאבלטים

  גרסת Android 3.2 כוללת מגוון אופטימיזציות במערכת כדי להבטיח חוויית משתמש מצוינת במגוון רחב יותר של מכשירי טאבלט.

• זום תאימות לאפליקציות בגודל קבוע

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

• סנכרון מדיה מכרטיס SD

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

תכונות חדשות למפתחים

• API מורחב לניהול תמיכה במסכים

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

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

סקירה כללית על API

ממשקי API לתמיכה במסכים

ב-Android 3.2 יש ממשקי API חדשים לתמיכה במסכים, שמעניקים לכם יותר שליטה על אופן הצגת האפליקציות שלכם בגודלי מסך שונים. ה-API מבוסס על ה-API הקיים עם תמיכה במסכים, כולל מודל צפיפות המסך הכללי של הפלטפורמה, אבל מרחיב אותו עם היכולת לטרגט באופן מדויק טווחי מסך ספציפיים לפי המידות שלהם, שנמדדים ביחידות פיקסלים שלא תלויות בדחיסות (כמו 600dp או 720dp ברוחב), במקום לפי גודל המסך הכללי (כמו גדול או xlarge)

כשאתם מתכננים את ממשק המשתמש של האפליקציה, אתם עדיין יכולים להסתמך על הפלטפורמה כדי לספק הפשטה של צפיפות, כלומר האפליקציות לא צריכות לפצות על ההבדלים בצפיפות הפיקסלים בפועל במכשירים השונים. אפשר לעצב את ממשק המשתמש של האפליקציה בהתאם למרחב האופקי או האנכי הזמין. הפלטפורמה מציגה את נפח המרחב הזמין באמצעות שלושה מאפיינים חדשים: smallestWidth,‏ width ו-height.

• הערך של smallestWidth של מסך הוא הגודל המינימלי הבסיסי שלו, שנמדד ביחידות של פיקסלים שלא תלויים בדחיסות (dp). המידה הקצרה מבין הגובה והרוחב של המסך. במסך בפריסה לאורך, הערך של smallestWidth מבוסס בדרך כלל על הרוחב, ובפריסה לרוחב הוא מבוסס על הגובה. בכל המקרים, הערך של smallestWidth נגזר ממאפיין קבוע של המסך, והוא לא משתנה ללא קשר לכיוון. הערך של smallestWidth חשוב לאפליקציות כי הוא מייצג את הרוחב הקצר ביותר שבו צריך לצייר את ממשק המשתמש של האפליקציה, לא כולל אזורי המסך ששמורים על ידי המערכת.
• לעומת זאת, הרוחב והגובה של המסך מייצגים את המרחב האנכי או האופקי הנוכחי שזמין לפריסת האפליקציה, שנמדד ביחידות dp, ולא כולל אזורים במסך ששמורים על ידי המערכת. הרוחב והגובה של המסך משתנים כשהמשתמש עובר בין כיוון לרוחב לבין כיוון התצוגה.

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

• מגדירי משאבים חדשים לטירגוט פריסות ומשאבים אחרים לרוחב, לגובה או ל-smallestWidth מינימלי, וגם
• מאפייני מניפסט חדשים, לציון טווח התאימות המקסימלי של המסך לאפליקציה

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

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

טבלה 1. מכשירים אופייניים, עם צפיפות וגודל ב-dp.

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

מגדירי משאבים חדשים לתמיכה במסכים

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

המאפיינים החדשים הם:

• swNNNdp — מציין את הרוחב המינימלי (smallestWidth) שבו צריך להשתמש במשאב, שנמדד ביחידות 'dp'. כפי שצוין למעלה, הערך של smallestWidth של המסך הוא קבוע, ללא קשר לכיוון. דוגמאות: sw320dp, sw720dp, sw720dp.
• wNNNdp ו-hNNNdp – קובעים את הרוחב או הגובה המינימלי שבו צריך להשתמש במשאב, שנמדדים ביחידות 'dp'. כפי שצוין למעלה, הרוחב והגובה של המסך הם ביחס לכיוון המסך, והם משתנים בכל פעם שהכיוון משתנה. דוגמאות: w320dp, w720dp, h1024dp.

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

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

res/layout/main_activity.xml   # For phones
res/layout-sw600dp/main_activity.xml   # For 7” tablets
res/layout-sw720dp/main_activity.xml   # For 10” tablets
res/layout-w600dp/main_activity.xml   # Multi-pane when enough width
res/layout-sw600dp-w720dp/main_activity.xml   # For large width

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

res/layout/main_activity.xml   # For phones
res/layout-xlarge/main_activity.xml   # For pre-3.2 tablets
res/layout-sw600dp/main_activity.xml   # For 3.2 and up tablets

למידע מלא על אופן השימוש במגדירי הגודל החדשים, ראו שימוש במגדירי גודל חדשים.

מאפייני מניפסט חדשים לתאימות לגודל המסך

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

מאפייני המניפסט החדשים לתמיכה במסך הם:

• android:compatibleWidthLimitDp="numDp" – המאפיין הזה מאפשר לציין את ה-smallestWidth המרבי שבו האפליקציה יכולה לפעול בלי צורך במצב תאימות. אם המסך הנוכחי גדול מהערך שצוין, המערכת תציג את האפליקציה במצב רגיל, אבל מאפשרת למשתמש לעבור באופן אופציונלי למצב תאימות באמצעות הגדרה בסרגל המערכת.
• android:largestWidthLimitDp="numDp" – המאפיין הזה מאפשר לציין את ה-smallestWidth המקסימלי שבו האפליקציה תוכננה לפעול. אם המסך הנוכחי גדול מהערך שצוין, המערכת מאלצת את האפליקציה לעבור למצב תאימות מסך כדי להבטיח את התצוגה הטובה ביותר במסך הנוכחי.
• android:requiresSmallestWidthDp="numDp" - המאפיין הזה מאפשר לציין את הרוחב המינימלי הקטן ביותר שבו האפליקציה תוכל לפעול. אם המסך הנוכחי קטן מהערך שצוין, המערכת מתייחסת לאפליקציה כלא תואמת למכשיר, אבל לא מונעת את ההתקנה וההפעלה שלה.

הערה: בשלב זה, Google Play לא מסנן אפליקציות על סמך אף אחד מהמאפיינים שלמעלה. תמיכה בסינון תתווסף במהדורה עתידית של הפלטפורמה. אפליקציות שצריכות לסנן לפי גודל המסך יכולות להשתמש במאפיינים הקיימים של <supports-screens>.

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

מצב תאימות מסך

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

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

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

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

צפיפות מסך חדשה לטלוויזיות 720p ולמכשירים דומים

כדי לענות על הצרכים של אפליקציות שפועלות בטלוויזיות 720p או דומות עם צפיפות מסך בינונית, ב-Android 3.2 נוספה צפיפות כללית חדשה, tvdpi, עם ערך dpi משוער של 213. אפליקציות יכולות לשלוח שאילתות לגבי הצפיפות החדשה ב-densityDpi, ולהשתמש במאפיין המסומן tvdpi כדי לתייג משאבים לטלוויזיות ולמכשירים דומים. לדוגמה:

res/drawable-tvdpi/my_icon.png   # Bitmap for tv density

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

מסגרת UI

• מקטעים
  • הכיתה החדשה Fragment.SavedState מכילה את פרטי המצב שאוחזרו ממופעי הפאזל באמצעות saveFragmentInstanceState().
  • השיטה החדשה saveFragmentInstanceState() שומרת את מצב המופע הנוכחי של ה-Fragment הנתון. אפשר להשתמש במצב מאוחר יותר כשיוצרים מופע חדש של ה-Fragment שמתאים למצב הנוכחי.
  • השיטה החדשה setInitialSavedState() מגדירה את המצב השמור הראשוני של Fragment כשהוא נוצר בפעם הראשונה.
  • שיטת ה-callback החדשה של onViewCreated() מעדכנת את ה-Fragment ש-onCreateView() חזר, אבל לפני שמצב שמור כלשהו שוחזר בתצוגה.
  • השיטה isDetached() קובעת אם ה-Fragment נותק באופן מפורש מממשק המשתמש.
  • שיטות חדשות של attach() ו-detach() מאפשרות לאפליקציה לצרף מחדש או לנתק קטעים בממשק המשתמש.
  • שיטת עומס יתר חדשה של setCustomAnimations() מאפשרת להגדיר משאבי אנימציה ספציפיים שיופעלו עבור פעולות כניסה/יציאה, ובמיוחד כשמוציאים פריטים מהמקבץ האחורי. ההטמעה הקיימת לא מביאה בחשבון את ההתנהגות השונה של קטעי קוד (fragments) כשמפעילים את הפעולה pop בסטור האחורי.
• מידע על גודל המסך ב-ActivityInfo וב-ApplicationInfo
  • ActivityInfo מוסיף את CONFIG_SCREEN_SIZE ו-CONFIG_SMALLEST_SCREEN_SIZE כמסכות ביטים ב-configChanges. הביטים מציינים אם הפעילות יכולה לטפל בעצמה בגודל המסך ובגודל המסך הקטן ביותר.
  • ApplicationInfo מוסיף את השדות largestWidthLimitDp,‏ compatibleWidthLimitDp ו-requiresSmallestWidthDp, שמבוססים על המאפיינים התואמים <supports-screens> בקובץ המניפסט של האפליקציה.
• כלים שעוזרים להציג את גודל התצוגה מ-windowManager
  • השיטות החדשות getSize() ו-getRectSize() מאפשרות לאפליקציות לקבל את הגודל הגולמי של המסך.
• סגנונות 'הולוגרפיים' חדשים שגלויים לכולם
  • עכשיו יש בפלטפורמה מגוון סגנונות 'הולוגרפיים' ציבוריים לטקסט, לווידג'טים ולכרטיסיות בסרגל הפעולות ועוד. לרשימה המלאה, אפשר לעיין ב-R.style.
• LocalActivityManager, ActivityGroup וגם LocalActivityManager הוצאו משימוש
  • באפליקציות חדשות צריך להשתמש ב-Fragments במקום בכיתות האלה. כדי להמשיך לפעול בגרסאות ישנות יותר של הפלטפורמה, אפשר להשתמש ב-v4 Support Library (ספריית התאימות), שזמינה ב-Android SDK. ספריית התמיכה בגרסה 4 מספקת גרסה של Fragment API שתואמת ל-Android 1.6 ואילך (רמת API 4).
  • באפליקציות שמפותחות ל-Android 3.0 ואילך (רמת API ‏11 ואילך), הכרטיסיות מוצגות בממשק המשתמש באמצעות ActionBar.newTab() החדש ו-APIs קשורים, כדי למקם את הכרטיסיות באזור של שורת הפעולות.

מסגרת מדיה

• אפליקציות שמשתמשות בספק המדיה של הפלטפורמה (MediaStore) יכולות עכשיו לקרוא נתוני מדיה ישירות מכרטיס ה-SD הנשלף, אם המכשיר תומך בכך. אפליקציות יכולות גם לבצע פעולות ישירות בקבצים בכרטיס ה-SD באמצעות MTP API.

גרפיקה

• פונקציות שימושיות לחלוקה לחלקים ב-Point וב-PointF
  • הכיתות Point ו-PointF כוללות עכשיו את ממשק Parcelable ואת שיטות התועלת describeContents(),‏ readFromParcel() ו-writeToParcel().

מסגרת IME

• שיטה חדשה getModifiers() לאחזור המצב הנוכחי של מקשי השינוי.

מסגרת USB

• שיטה חדשה של getRawDescriptors() לאחזור מתארי ה-USB הגולמיים של המכשיר. אפשר להשתמש בשיטה הזו כדי לגשת למאפייני תיאור שלא נתמכים ישירות דרך ממשקי ה-API ברמה גבוהה יותר.

רשת

• קבועים של סוג הרשת
  • ConnectivityManager מוסיף את הקבועים TYPE_ETHERNET ו-TYPE_BLUETOOTH.

טלפוניה

• קבוע חדש מסוג רשת NETWORK_TYPE_HSPAP.

שירותי ליבה

• כלי עזר שניתן לחלק למקטעים
  • הממשק החדש Parcelable.ClassLoaderCreator מאפשר לאפליקציה לקבל את ה-ClassLoader שבו האובייקט נוצר.
  • ההרשאות החדשות adoptFd,‏ dup() ו-fromFd() לניהול אובייקטים מסוג ParcelFileDescriptor.
• Binder ו-IBinder
  • השיטה החדשה dumpAsync() ב-Binder וב-IBinder מאפשרת לאפליקציות לבצע העברה לקובץ ספציפי, כדי להבטיח שהיעד פועל באופן אסינכרוני.
  • קוד הטרנזקציה החדש של פרוטוקול IBinder‏ TWEET_TRANSACTION מאפשר לאפליקציות לשלוח ציוץ לאובייקט היעד.

קבועים חדשים של תכונות

הפלטפורמה מוסיפה קבועים חדשים של תכונות חומרה, שאפשר להצהיר עליהם במניפסטים של האפליקציות כדי להודיע לישויות חיצוניות כמו Google Play על יכולות החומרה והתוכנה הנדרשות. מגדירים את הקבועים האלה ואת קבועי התכונות האחרים ברכיבי המניפסט <uses-feature>.

Google Play מסנן אפליקציות על סמך המאפיינים שלהן ב-<uses-feature>, כדי לוודא שהן זמינות רק למכשירים שעומדים בדרישות שלהן.

• מאפייני קבועים לדרישות של תמונות בפורמט לרוחב או לאורך

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

  • android.hardware.screen.landscape – האפליקציה דורשת תצוגה במצב לרוחב.
  • android.hardware.screen.portrait – האפליקציה דורשת תצוגה בפורמט לאורך.

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

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

• קבועים אחרים של תכונות
  • android.hardware.faketouch.multitouch.distinct – האפליקציה דורשת תמיכה בקלט מולטי-טאץ (emulated mulitouch) עם מעקב נפרד אחרי שתי נקודות או יותר.
  • android.hardware.faketouch.multitouch.jazzhand — האפליקציה דורשת תמיכה בקלט של מגע רב-משתמש (multitouch) עם מעקב נפרד אחרי חמש נקודות או יותר.

דוח ההבדלים בין ממשקי ה-API

כדי לראות תצוגה מפורטת של כל השינויים ב-API ב-Android 3.2 (רמת API 13), אפשר לעיין בדוח ההבדלים ב-API.

רמת ה-API

פלטפורמת Android 3.2 מספקת גרסה מעודכנת של ה-framework API. ל-Android 3.2 API מוקצה מזהה שלם – 13 – שנשמר במערכת עצמה. המזהה הזה, שנקרא 'רמת ה-API', מאפשר למערכת לקבוע בצורה נכונה אם אפליקציה תואמת למערכת, לפני התקנת האפליקציה.

כדי להשתמש בממשקי API שנוצרו ב-Android 3.2 באפליקציה שלכם, צריך להדר את האפליקציה בספריית Android שסופקה בפלטפורמת ה-SDK של Android 3.2. בהתאם לצרכים שלכם, יכול להיות שתצטרכו להוסיף גם מאפיין android:minSdkVersion="13" לאלמנט <uses-sdk> במניפסט של האפליקציה.

מידע נוסף זמין במאמר מהו רמת API?