ממשקי API של Android 4.0

רמת ה-API: 14

Android 4.0 (ICE_CREAM_SANDWICH) היא גרסה מרכזית של הפלטפורמה שמוסיפה מגוון תכונות חדשות למשתמשים ולמפתחי אפליקציות. חוץ מכל התכונות וממשקי ה-API החדשים שמפורטים בהמשך, גרסת Android 4.0 היא השקת פלטפורמה מפני שהיא מספקת את המגוון הרחב של ממשקי API ועיצובים הולוגרפיים מ-Android 3.x למסכים קטנים יותר. מפתחי אפליקציות יכולים עכשיו להשתמש בפלטפורמה אחת ובמסגרת אחידה של ממשקי API כדי לפתח ולפרסם אפליקציות באמצעות קובץ APK אחד. קובץ ה-APK הזה מספק חוויית משתמש אופטימלית למכשירי טלפון, טאבלטים ועוד, כשהם פועלים באותה גרסת Android – Android 4.0 (רמת API 14) ואילך.

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

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

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

ממשקי API של רשתות חברתיות ב'ניהול אנשי הקשר'

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

פרופיל משתמש

Android כולל עכשיו פרופיל אישי שמייצג את בעל המכשיר, כפי שמוגדר על ידי טבלה של ContactsContract.Profile. אפליקציות רשתות חברתיות שמנהלות את זהות המשתמש יכולות לתרום לנתוני הפרופיל של המשתמש על ידי יצירת רשומה חדשה של ContactsContract.RawContacts ב-ContactsContract.Profile. כלומר, אנשי קשר גולמיים שמייצגים את המשתמש במכשיר לא משתייכים לטבלה המסורתית של אנשי הקשר הגולמיים שהוגדרה על ידי ה-URI של ContactsContract.RawContacts; במקום זאת, עליך להוסיף איש קשר גולמי של פרופיל הטבלה שבכתובת CONTENT_RAW_CONTACTS_URI. גולמי לאחר מכן, אנשי הקשר שבטבלה זו מתווספים לפרופיל היחיד הגלוי למשתמש, בתווית 'אני'.

כדי להוסיף איש קשר גולמי חדש עבור הפרופיל, הרשאה android.Manifest.permission#WRITE_PROFILE. באופן דומה, כדי לקרוא מטבלת הפרופיל, צריך לבקש את ההרשאה android.Manifest.permission#READ_PROFILE. אבל, לפעמים רוב האפליקציות לא צריכות לקרוא את פרופיל המשתמש, גם אם הן תורמות נתונים פרופיל. קריאת פרופיל המשתמש היא הרשאה רגישת, וצריך לצפות שהמשתמשים יהיו ספקנים לגבי אפליקציות שמבקשות אותה.

הכוונה (Intent) של ההזמנה

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

כדי שהאפליקציה תהיה גלויה כמו ב'הוספת חיבור' הרשימה, האפליקציה שלך צריכה לספק מתאם סנכרון לסנכרן פרטים של אנשי קשר מהרשת החברתית שלך. לאחר מכן, צריך לציין למערכת שהאפליקציה שלכם מגיבה ל-Intent‏ INVITE_CONTACT על ידי הוספת המאפיין inviteContactActivity לקובץ התצורה של הסנכרון של האפליקציה, עם שם מלא ומפורט של הפעילות שהמערכת צריכה להתחיל כששולחים את ה-Intent של ההזמנה. לאחר מכן, הפעילות שתתחיל תוכל לאחזר את מזהה ה-URI של איש הקשר הרלוונטי מהנתונים של הכוונה, ולבצע את הפעולות הנדרשות כדי להזמין את איש הקשר הזה לרשת או להוסיף את המשתמש לחברים של המשתמש.

תמונות גדולות

מעכשיו יש תמיכה ב-Android בתמונות ברזולוציה גבוהה של אנשי קשר. עכשיו, כשדוחפים תמונה לתוך רשומת איש קשר, המערכת מעבדת אותה גם לתמונה ממוזערת בגודל 96x96 (כפי שעשתה בעבר) וגם "תמונה לתצוגה" בגודל 256x256 שמאוחסנים בחנות תמונות חדשה שמבוססת על קבצים (המידות המדויקות של המערכת עשויה להשתנות בעתיד). ניתן להוסיף תמונה גדולה לאנשי קשר באמצעות הצבת תמונה גדולה בעמודה PHOTO הרגילה של שורת נתונים, שאותה המערכת תעבד לאחר מכן לתמונה הממוזערת ולתמונה המוצגת רשומות.

שליחת משוב על שימוש

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

ספק היומן

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

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

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

  • בטבלה CalendarContract.Calendars יש נתונים ספציפיים ליומן מידע. כל שורה בטבלה הזו כוללת את הפרטים של יומן מסוים, כמו השם שלו, צבע, סנכרון מידע וכו'.
  • הטבלה CalendarContract.Events מכילה מידע ספציפי לאירוע. כל שורה בטבלה הזו מכילה את המידע של אירוע אחד, כמו כותרת האירוע, מיקום, שעת התחלה, שעת סיום וכן הלאה. האירוע יכול להתרחש פעם אחת או לחזור על עצמו כמה פעמים. המשתתפים, התזכורות והנכסים המורחבים מאוחסנים בטבלאות נפרדות להשתמש ב-_ID של האירוע כדי לקשר אותם לאירוע.
  • בטבלה CalendarContract.Instances נשמרות שעות ההתחלה והסיום של אירועים. כל שורה בטבלה הזו מייצגת אירוע יחיד. לאירועים חד-פעמיים יש מיפוי אחד לאחד של מופעים לאירועים. באירועים חוזרים, צריך לבצע כמה שורות נוצר באופן אוטומטי בהתאם למופעים המרובים של אותו אירוע.
  • הטבלה CalendarContract.Attendees מכילה את המשתתף או האורח באירוע מידע. כל שורה מייצגת אורח אחד באירוע. מציין את סוג האורח הוא שלו, והתשובה של אותו אדם לאירוע.
  • הטבלה CalendarContract.Reminders מכילה את נתוני ההתראה/התראה. כל שורה מייצגת התראה אחת על אירוע. לכל אירוע יכולות להיות כמה תזכורות. מספר תזכורות לכל אירוע מצוינות ב-MAX_REMINDERS, שמוגדר על ידי מתאם הסנכרון הוא הבעלים של היומן הנתון. התזכורות מסומנות מספר דקות לפני האירוע לתזמן ולקבוע שיטת התראה, למשל להשתמש בהתראה, באימייל או ב-SMS כדי להזכיר להם. למשתמש.
  • בטבלה CalendarContract.ExtendedProperties יש שדות נתונים אטומים בשימוש של מתאם הסנכרון. הספק לא מבצע פעולות כלשהן בפריטים בטבלה הזו, מלבד מחיקה שלהם כשהאירועים הקשורים אליהם נמחקים.

כדי לגשת לנתוני היומן של משתמש באמצעות ספק היומן, האפליקציה צריכה לבקש את ההרשאה READ_CALENDAR (לגישה לקריאה) ואת ההרשאה WRITE_CALENDAR (לגישה לכתיבה).

כוונה של משתמש באירוע

אם רוצים רק להוסיף אירוע ליומן של המשתמש, אפשר להשתמש ב-Intent ACTION_INSERT עם הנתונים שמוגדרים על ידי Events.CONTENT_URI כדי להתחיל פעילות באפליקציית יומן Google שיוצרת אירועים חדשים. אין צורך בהרשאה כדי להשתמש בכוונה, ואפשר לציין את פרטי האירוע באמצעות התוספים הבאים:

ספק דואר קולי

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

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

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

מולטימדיה

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

אפקטים של מדיה

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

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

  1. הם חייבים להיות מקושרים לתמונה של טקסטורה מסוג GL_TEXTURE_2D
  2. הן חייבות להכיל לפחות רמת Mipmap אחת

אובייקט Effect מגדיר אפקט מדיה יחיד שאפשר להחיל עליו מסגרת לתמונה. תהליך העבודה הבסיסי ליצירת Effect הוא:

  1. קוראים ל-EffectContext.createWithCurrentGlContext() מההקשר של OpenGL ES 2.0.
  2. משתמשים בפונקציה EffectContext שהוחזרה כדי להפעיל את הפונקציה EffectContext.getFactory(), שמחזירה מופע מתוך EffectFactory.
  3. קוראים ל-createEffect() ומעבירים לה שם של אפקט מ-@link android.media.effect.EffectFactory}, כמו EFFECT_FISHEYE או EFFECT_VIGNETTE.

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

כדי להחיל אפקט על טקסטורה, יש לקרוא ל-apply() Effect ולהעביר את טקסטורת הקלט, את הרוחב והגובה שלו, ואת הפלט טקסטורה. מרקם הקלט חייב להיות קשור למרקם GL_TEXTURE_2D תמונה (בדרך כלל נעשה על ידי קריאה ל-glTexImage2D()) ). אפשר לציין כמה רמות של מיילים ב-Mipmap. אם מרקם הפלט לא קושר תמונת טקסטורה, היא תהיה משויכת באופן אוטומטי לאפקט GL_TEXTURE_2D ועם רמת Mipmap אחת (0), שתהיה לה אותה גודל כקלט.

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

לקוח שלט רחוק

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

כדי להפעיל לקוחות של שליטה מרחוק בנגן המדיה, יוצרים מופע של RemoteControlClient באמצעות ה-constructor שלו, ומעבירים לו PendingIntent שמקריא את ACTION_MEDIA_BUTTON. אפליקציית Intent צריכה גם להצהיר על רכיב ה-BroadcastReceiver המפורש באפליקציה שלכם שמטפל באירוע ACTION_MEDIA_BUTTON.

כדי להצהיר על הקלטות של פקדי המדיה שהנגן יכול לטפל בהן, צריך להפעיל את setTransportControlFlags() ב-RemoteControlClient, ולהעביר קבוצה של דגלים של FLAG_KEY_MEDIA_*, כמו FLAG_KEY_MEDIA_PREVIOUS ו-FLAG_KEY_MEDIA_NEXT.

לאחר מכן עליך לרשום את RemoteControlClient על ידי העברתו אל MediaManager.registerRemoteControlClient(). לאחר הרישום, מקלט השידור שהצהרתם עליו כשיצרתם את RemoteControlClient יקבל אירועי ACTION_MEDIA_BUTTON כשמקישים על לחצן בשלט רחוק. ה-Intent שמתקבל כולל את השדה KeyEvent של מקש המדיה שעליו לחצת, ואפשר לאחזר אותו מה-Intent באמצעות getParcelableExtra(Intent.EXTRA_KEY_EVENT).

כדי להציג בשלט הרחוק מידע על המדיה שמופעלת, צריך להפעיל את editMetaData() ולהוסיף מטא-נתונים ל-RemoteControlClient.MetadataEditor המוחזר. אתם יכולים לספק קובץ בייטמאפ לגרפיקת המדיה, מידע מספרי כמו משך הזמן שחלף ומידע טקסטואלי כמו שם הטראק. מידע על המפתחות הזמינים זמין בדגלים METADATA_KEY_* בקובץ MediaMetadataRetriever.

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

נגן מדיה

  • מעכשיו, כדי לשדר מדיה בסטרימינג אונליין מ-MediaPlayer, נדרשת ההרשאה INTERNET. אם משתמשים ב-MediaPlayer כדי להפעיל תוכן מהאינטרנט, הקפידו להוסיף את INTERNET הרשאה למניפסט שלך, אחרת הפעלת המדיה לא תפעל החל מ-Android 4.0.
  • setSurface() מאפשר להגדיר Surface שיתנהג בהתאם ל-sink הסרטון.
  • setDataSource() מאפשר לך לשלוח כותרות HTTP נוספות יחד עם הבקשה, שיכולות להיות שימושיות לסטרימינג בשידור חי מסוג HTTP(S)
  • סטרימינג בשידור חי ב-HTTP(S) מתייחס עכשיו לקובצי cookie של HTTP בכל הבקשות

סוגי המדיה

ב-Android 4.0 נוספת תמיכה בתכונות הבאות:

  • גרסה 3 של פרוטוקול סטרימינג בשידור חי ב-HTTP/HTTPS
  • קידוד אודיו של AAC גולמי של ADTS
  • תמונות WEBP
  • סרטון Matroska

מידע נוסף זמין במדיה נתמכת פורמטים.

מצלמה

בכיתה Camera יש עכשיו ממשקי API לזיהוי פנים ולבקרה תחומי מיקוד ומדידה.

איתור פנים

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

כדי לזהות פנים באפליקציית המצלמה, עליך לרשום Camera.FaceDetectionListener בהתקשרות אל setFaceDetectionListener(). לאחר מכן תוכלו להתחיל להשתמש במשטח המצלמה ולזהות פנים על ידי השמעת הפקודה startFaceDetection().

כשהמערכת מזהה פנים של אדם אחד או יותר בסצנת המצלמה, היא מבצעת קריאה חוזרת (callback) של onFaceDetection() ב של Camera.FaceDetectionListener, כולל מערך Camera.Face אובייקטים.

מופע של הכיתה Camera.Face מספק מידע שונה על הפנים שזוהו, כולל:

  • Rect שמציין את גבולות הפנים, ביחס לגבולות של המצלמה שדה הראייה הנוכחי
  • מספר שלם בין 1 ל-100 שמציין את מידת הביטחון של המערכת בכך שהאובייקט פנים אנושיות
  • מזהה ייחודי כדי שתוכלו לעקוב אחרי כמה פנים
  • מספר אובייקטים מסוג Point שמציינים את מיקום העיניים והפה נמצא

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

אזורי מיקוד ומדידה

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

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

כדי לציין את אזורי המיקוד או המדידה שבהם רוצים להשתמש, פשוט קוראים לפונקציה setFocusAreas() או setMeteringAreas(). כל אחד מהם לוקח List מתוך Camera.Area אובייקטים שמציינים את האזורים שצריך לקחת בחשבון למיקוד או למדידת ביצועים. לדוגמה, אפשר להטמיע תכונה שמאפשרת למשתמש להגדיר את אזור המיקוד על ידי מגע באזור בתצוגה המקדימה, ולאחר מכן לתרגם אותו לאובייקט Camera.Area ולבקש מהמצלמה להתמקד באזור הזה בסצנה. המיקוד או החשיפה באזור הזה יתעדכנו באופן קבוע ככל שהסצנה באזור תשתנה.

מיקוד אוטומטי רציף לתמונות

עכשיו אפשר להפעיל מיקוד אוטומטי רציף (CAF) בזמן צילום תמונות. כדי להפעיל CAF ב- אפליקציית מצלמה, העברת FOCUS_MODE_CONTINUOUS_PICTURE אל setFocusMode(). כשרוצים לצלם תמונה, מקישים על autoFocus(). ה-Camera.AutoFocusCallback מקבל קריאה חוזרת באופן מיידי כדי לציין אם המערכת הצליחה להתמקד. כדי להמשיך את ה-CAF אחרי קבלת השיחה החוזרת, צריך להתקשר למספר cancelAutoFocus().

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

תכונות אחרות של המצלמה

  • בזמן צילום וידאו, אפשר עכשיו להתקשר למספר takePicture() כדי לשמור תמונה בלי להפסיק את סשן הווידאו. לפני כן, צריך להתקשר למספר isVideoSnapshotSupported() כדי לוודא שהחומרה תומכת בכך.
  • עכשיו אפשר לנעול חשיפה אוטומטית ואיזון לבן באמצעות setAutoExposureLock() ו-setAutoWhiteBalanceLock() כדי למנוע כדי למנוע שינויים במאפיינים האלה.
  • עכשיו אפשר להתקשר אל setDisplayOrientation() בזמן שהתצוגה המקדימה של המצלמה פועלת. בעבר, אפשר היה לבצע את הפעולה הזו רק לפני תחילת התצוגה המקדימה, אבל עכשיו אפשר לשנות את הכיוון בכל שלב.

כוונות שידור מהמצלמה

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

Android Beam (NDEF Push with NFC)

Android Beam היא תכונת NFC חדשה שמאפשרת לשלוח הודעות NDEF ממכשיר אחד אל אחר (תהליך שנקרא גם "דחיפת NDEF"). העברת הנתונים מתחילה כאשר מכשירים מבוססי Android שתומכים ב-Android Beam נמצאים בסמוך (כ-4 ס"מ), בדרך כלל עם הגבים שלהם נוגעים. הנתונים שבהודעת ה-NDEF יכולים להכיל כל נתון שרוצים לשתף בין מכשירים. לדוגמה, אפליקציית 'אנשים' משתפת אנשי קשר, משתפת סרטונים ומנהלת את הדפדפן ב-YouTube משתף כתובות URL באמצעות Android Beam.

כדי להעביר נתונים בין מכשירים באמצעות Android Beam, עליך ליצור NdefMessage שמכיל את המידע שברצונך לשתף בזמן שהפעילות מתבצעת את החזית. לאחר מכן צריך להעביר את NdefMessage למערכת באחד מתוך שניים דרכים:

  • הגדרת NdefMessage יחיד לדחיפה בזמן הפעילות:

    אפשר להתקשר למספר setNdefPushMessage() בכל שלב כדי להגדיר את ההודעה שרוצים לשלוח. לדוגמה, אפשר לקרוא לשיטה הזו ולהעביר לה את NdefMessage במהלך onCreate() של הפעילות . לאחר מכן, בכל פעם ש-Android Beam מופעל במכשיר אחר בזמן שהפעילות בחזית, המערכת שולחת את NdefMessage למכשיר השני.

  • הגדרת ה-NdefMessage לדחיפה בזמן הפעלת Android Beam:

    מטמיעים את NfcAdapter.CreateNdefMessageCallback, שבה ההטמעה של השיטה createNdefMessage() מחזירה את ה-NdefMessage שרוצים לשלוח. לאחר מכן מעבירים את ההטמעה של NfcAdapter.CreateNdefMessageCallback אל setNdefPushMessageCallback().

    במקרה כזה, כש-Android Beam מופעל עם מכשיר אחר בזמן שהפעילות שלכם בחזית, המערכת קוראת ל-createNdefMessage() כדי לאחזר את ה-NdefMessage שרוצים לשלוח. כך תוכלו להגדיר את NdefMessage כך שיישלח רק פעם אחת כשהפעלת Android Beam תתחיל, למקרה שתוכן ההודעה ישתנה במהלך הפעילות.

אם אתם רוצים להריץ קוד ספציפי אחרי שהמערכת תצליח להעביר את הודעת ה-NDEF למכשיר השני, תוכלו להטמיע את NfcAdapter.OnNdefPushCompleteCallback ולהגדיר אותו באמצעות setNdefPushCompleteCallback(). המערכת לאחר מכן יש להתקשר למספר onNdefPushComplete() כשההודעה תימסר.

במכשיר המקבל, המערכת שולחת הודעות NDEF בדחיפה באופן דומה להודעות NFC רגילות. התגים. המערכת מפעילה כוונה עם הפעולה ACTION_NDEF_DISCOVERED כדי להתחיל פעילות, עם כתובת URL או סוג MIME שהוגדרו בהתאם ל-NdefRecord הראשון ב-NdefMessage. לגבי הפעילות שאתם רוצים יש לך אפשרות להצהיר על מסנני Intent של כתובות ה-URL או סוגי MIME שחשובים לאפליקציה. לקבלת מידע נוסף מידע על Tag Dispatch זמין במדריך למפתחים של NFC.

אם רוצים שה-NdefMessage יכלול URI, אפשר עכשיו להשתמש במאפיין הנוחות השיטה createUri כדי ליצור NdefRecord חדש על סמך מחרוזת או אובייקט Uri. אם ה-URI הוא בפורמט מיוחד שאתם רוצים שהאפליקציה תקבל גם במהלך אירוע Android Beam, עליכם ליצור מסנן כוונה לפעילות שלכם באמצעות אותו סכימה של URI כדי לקבל את הודעת ה-NDEF הנכנסת.

עליך גם להעביר 'רשומה של אפליקציה ל-Android' עם NdefMessage ב- כדי להבטיח שהאפליקציה תטפל בהודעת ה-NDEF הנכנסת, גם אם היא מסננים של אפליקציות לאותה פעולת Intent. אפשר ליצור רשומה של אפליקציה ל-Android באמצעות התקשרות אל createApplicationRecord(), העברה שם החבילה של האפליקציה. כשהמכשיר השני מקבל את הודעת ה-NDEF עם רשומת האפליקציה, וכמה אפליקציות מכילות פעילויות שמטפלות בכוונה שצוינה, המערכת תמיד מעבירה את ההודעה לפעילות באפליקציה שלכם (על סמך רשומת האפליקציה התואמת). אם האפליקציה לא מותקנת כרגע במכשיר היעד, המערכת משתמשת ברשומת האפליקציה ל-Android כדי להפעיל את Google Play ולהעביר את המשתמש לאפליקציה כדי להתקין אותה.

אם האפליקציה שלך לא משתמשת בממשקי API של NFC כדי לבצע העברת הודעות NDEF Push, Android מספק התנהגות ברירת המחדל: כשהאפליקציה פועלת בחזית במכשיר אחד ו-Android Beam מופעל באמצעות מכשיר אחר המבוסס על Android, והמכשיר השני מקבל הודעת NDEF עם רשומה של אפליקציית Android שמזהה את האפליקציה שלכם. אם במכשיר המקבל יש את מותקנת, המערכת מפעילה אותו; אם האפליקציה לא מותקנת, אפליקציית Google Play נפתחת ומצלמת המשתמש הרלוונטי באפליקציה כדי להתקין אותה.

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

Wi-Fi P2P

Android תומך עכשיו בחיבורי Wi-Fi מקצה לקצה (P2P) בין מכשירים מבוססי Android לבין סוגים אחרים של מכשירים (בהתאם ל-Wi-Fi DirectTM של Wi-Fi Alliance תוכנית הסמכה) ללא נקודה לשיתוף אינטרנט (Hotspot) או חיבור לאינטרנט. מסגרת Android מספקת קבוצה של ממשקי API של Wi-Fi P2P שמאפשרים לכם לגלות מכשירים אחרים ולהתחבר אליהם כשכל מכשיר תומך ב-Wi-Fi P2P, ואז לתקשר דרך חיבור מהיר למרחקים ארוכים בהרבה מאשר חיבור Bluetooth.

חבילת android.net.wifi.p2p החדשה מכילה את כל ממשקי ה-API לביצוע חיבורים peer-to-peer באמצעות Wi-Fi. הכיתה העיקרית שאיתה צריך לעבוד היא WifiP2pManager. אפשר לרכוש אותה בהתקשרות אל getSystemService(WIFI_P2P_SERVICE). WifiP2pManager כולל ממשקי API שמאפשרים לכם:

  • לאתחל את האפליקציה לחיבורי P2P על ידי התקשרות אל initialize()
  • רוצה למצוא מכשירים בקרבת מקום? ניתן להתקשר אל discoverPeers()
  • כדי להתחיל חיבור P2P, צריך להתקשר אל connect()
  • ועוד

נדרשים גם כמה ממשקים וכיתות נוספים, כמו:

  • הממשק WifiP2pManager.ActionListener מאפשר לקבל קריאות חזרה (callbacks) כשפעולה כמו גילוי עמיתים או חיבור אליהם מסתיימת בהצלחה או נכשלת.
  • הממשק של WifiP2pManager.PeerListListener מאפשר לך לקבל מידע על אפליקציות להשוואה שנמצאו. הקריאה החוזרת (callback) מספקת WifiP2pDeviceList, שבאמצעותו אפשר לאחזר אובייקט WifiP2pDevice לכל מכשיר שנמצא בטווח, ולקבל מידע כמו שם המכשיר, הכתובת, סוג המכשיר, הגדרות ה-WPS שבהן המכשיר תומך ועוד.
  • הממשק של WifiP2pManager.GroupInfoListener מאפשר לכם לקבל מידע על קבוצת P2P. פונקציית ה-callback מספקת אובייקט WifiP2pGroup, שמספק מידע על הקבוצה, כמו הבעלים, שם הרשת והביטוי המוצפן.
  • הממשק WifiP2pManager.ConnectionInfoListener מאפשר לקבל מידע על החיבור הנוכחי. פונקציית ה-callback מספקת אובייקט WifiP2pInfo, שמכיל מידע כמו אם הקבוצה נוצרה ומי הבעלים שלה.

כדי להשתמש בממשקי ה-API של Wi-Fi P2P, האפליקציה שלך צריכה לבקש את הרשאות המשתמש הבאות:

  • ACCESS_WIFI_STATE
  • CHANGE_WIFI_STATE
  • INTERNET (למרות שהאפליקציה שלך לא מתחברת מבחינה טכנית לאינטרנט, תקשורת עם עמיתים ב-Wi-Fi P2P שיש להם שקעי Java רגילים מחייבת חיבור לאינטרנט ).

מערכת Android משדרת גם כמה פעולות שונות במהלך אירועי Wi-Fi P2P מסוימים:

מידע נוסף זמין במסמכי התיעוד של WifiP2pManager. כדאי גם לעיין באפליקציה לדוגמה Wi-Fi P2P Demo.

מכשירי Bluetooth Health

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

בדומה לאוזניות רגילות ולמכשירים עם פרופיל A2DP, כדי ליצור חיבור לפרופיל צריך להפעיל את getProfileProxy() עם BluetoothProfile.ServiceListener ועם סוג הפרופיל HEALTH אובייקט proxy.

אחרי שרוכשים את שרת ה-Proxy של פרופיל הבריאות (BluetoothHealth ), כשמתחברים למכשירי בריאות מותאמים ומתקשרים איתם, יש את הכלים הבאים סיווגי Bluetooth:

  • BluetoothHealthCallback: צריך להרחיב את הכיתה הזו ולהטמיע את שיטות ה-callback כדי לקבל עדכונים על שינויים במצב הרישום של האפליקציה ובמצב של ערוץ ה-Bluetooth.
  • BluetoothHealthAppConfiguration: במהלך קריאות חוזרות אל BluetoothHealthCallback, יתקבל מופע של האובייקט הזה מספקת פרטי תצורה על המכשיר הזמין של תקינות ה-Bluetooth, שבו צריך להשתמש כדי לבצע פעולות שונות כמו ליזום ולסיים חיבורים עם ממשקי ה-API של BluetoothHealth.

מידע נוסף על השימוש בפרופיל Health ב-Bluetooth זמין במסמכים של BluetoothHealth.

נגישות

מערכת Android 4.0 משפרת את הנגישות למשתמשים ליקויי ראייה באמצעות מצב חדש של 'גילוי באמצעות מגע' וממשקי API מורחבים שמאפשרים לספק מידע נוסף על תוכן של צפיות לפתח שירותי נגישות מתקדמים.

מצב 'גילוי באמצעות מגע'

משתמשים עם לקות ראייה יכולים עכשיו לבחון את המסך על ידי מגע וגרירה של אצבע על המסך, כדי לשמוע תיאורים קוליים של התוכן. כי מצב 'גילוי אחר מגע' פועל כמו סמן וירטואלי, הוא מאפשר לקוראי מסך לזהות את הטקסט התיאורי באותו אופן שבו לקוראים יכולים לעשות זאת כשהמשתמש מנווט באמצעות מקשי החיצים (d-pad או כדור עקיבה) על ידי קריאת המידע שסופק על ידי android:contentDescription ועל setContentDescription() במהלך סימולציה של 'מעבר מעל עכבר' אירוע. אז, זאת תזכורת לכך שצריך לספק טקסט תיאורי עבור התצוגות במיוחד לאפליקציות ImageButton, EditText, ImageView ווידג'טים אחרים שעשויים לא לכלול באופן טבעי תיאורים טקסט.

נגישות לתצוגות

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

חשוב לזכור קודם כל שההתנהגות של השיטה sendAccessibilityEvent() השתנתה ב-Android 4.0. בדומה לגרסאות קודמות של Android, כשהמשתמש מפעיל את שירותי הנגישות במכשיר ומתרחש אירוע קלט כמו קליק או מעקב עכבר, התצוגה המתאימה מקבלת הודעה באמצעות קריאה ל-sendAccessibilityEvent(). בעבר, ההטמעה של sendAccessibilityEvent() הייתה מפעילה AccessibilityEvent ושולחת אותו אל AccessibilityManager. ההתנהגות החדשה כוללת כמה שיטות קריאה חוזרת (callbacks) נוספות שמאפשרות לתצוגה ולרכיבי ההורה שלה להוסיף לאירוע מידע נוסף על ההקשר:

  1. בהפעלה, השיטות sendAccessibilityEvent() ו-sendAccessibilityEventUnchecked() דוחות דחייה אל onInitializeAccessibilityEvent().

    ייתכן שהטמעות מותאמות אישית של View יטמיעו את onInitializeAccessibilityEvent() לצרף מידע נוסף על נגישות ל-AccessibilityEvent, אבל צריך גם לבצע קריאה להטמעה של: לספק פרטי ברירת מחדל, כמו תיאור התוכן הרגיל, אינדקס הפריטים ועוד. אבל לא כדאי להוסיף תוכן טקסט נוסף בקריאה החוזרת (callback) – זה קורה הבא.

  2. אחרי האתחול, אם האירוע הוא אחד מכמה סוגים שצריך לאכלס בטקסט מידע, התצוגה תקבל קריאה אל dispatchPopulateAccessibilityEvent(), נוטרת ל-onPopulateAccessibilityEvent() קריאה חוזרת.

    בדרך כלל, בהטמעות בהתאמה אישית של View צריך להטמיע את onPopulateAccessibilityEvent() כדי להוסיף תוכן טקסט נוסף ל-AccessibilityEvent אם הטקסט של android:contentDescription חסר או לא מספיק. כדי להוסיף עוד טקסט תיאור AccessibilityEvent, שיחה אל getText().add().

  3. בשלב הזה, ה-View מעביר את האירוע למעלה בהיררכיית התצוגות באמצעות קריאה לפעולה requestSendAccessibilityEvent() ב- תצוגה ראשית. לכל תצוגת הורה יש הזדמנות לשפר את נתוני הנגישות על ידי הוספה של AccessibilityRecord, עד הוא מגיע בסופו של דבר לתצוגת הבסיס, ששולח את האירוע אל AccessibilityManager עם sendAccessibilityEvent().

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

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

שירותי נגישות

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

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

  1. עם קבלת AccessibilityEvent מאפליקציה, קוראים ל-AccessibilityEvent.getRecord() כדי לאחזר AccessibilityRecord ספציפי (ייתכן שצורפו כמה רשומות אירוע).
  2. מ-AccessibilityEvent או מ-AccessibilityRecord ספציפי, אפשר לקרוא ל-getSource() כדי לאחזר אובייקט AccessibilityNodeInfo.

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

  3. באמצעות AccessibilityNodeInfo, אפשר לשלוח שאילתות לגבי המידע שלו, להפעיל את getParent() או getChild() כדי לעבור את היררכיית התצוגה, ואפילו להוסיף לצומת תצוגות צאצא.

כדי שהאפליקציה שלך תפרסם את עצמה במערכת בתור שירות נגישות, היא חייבת להצהיר על קובץ תצורה של XML שתואם ל-AccessibilityServiceInfo. כדי לקבל מידע נוסף על יצירת מידע על תצורת ה-XML מופיע במאמרים AccessibilityService ו-SERVICE_META_DATA.

ממשקי API אחרים לנגישות

אם מעניין אותך את מצב הנגישות של המכשיר, יש ב-AccessibilityManager כמה ממשקי API חדשים, כמו:

שירותי בדיקת איות

מסגרת חדשה לבדיקת איות מאפשרת לאפליקציות ליצור כלי בדיקת איות באופן דומה למסגרת של שיטות הקלט (ל-IME). כדי ליצור בדיקת איות חדשה, צריך להטמיע שירות נמשך SpellCheckerService ולהרחיב את הכיתה SpellCheckerService.Session כדי לספק הצעות איות על סמך בטקסט שמסופק על ידי שיטות הקריאה החוזרת (callback) של הממשק. ב-methods של הקריאה החוזרת (callback) ב-SpellCheckerService.Session, צריך להחזיר את הצעות איות כאובייקטים SuggestionsInfo.

אפליקציות עם שירות של בדיקת איות חייבות להצהיר על ההרשאה BIND_TEXT_SERVICE כנדרש על ידי השירות. השירות צריך גם להצהיר על מסנן כוונה עם <action android:name="android.service.textservice.SpellCheckerService" /> כפעולת הכוונה, ולכלול רכיב <meta-data> שמצהיר על פרטי ההגדרה של בדיקת האיות.

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

מנועים להמרת טקסט לדיבור (TTS)

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

שימוש במנועי המרת טקסט לדיבור (TTS)

בגרסאות קודמות של Android, היה אפשר להשתמש במחלקה TextToSpeech כדי לבצע פעולות של המרת טקסט לדיבור (TTS) באמצעות מנוע ה-TTS שסופק על ידי המערכת, או כדי להגדיר מנוע מותאם אישית באמצעות setEngineByPackageName(). ב-Android 4.0, השיטה setEngineByPackageName() כבר הוצא משימוש ועכשיו אפשר להגדיר את המנוע לשימוש עם constructor חדש של TextToSpeech שמקבל את שם החבילה של מנוע TTS.

אפשר גם לשלוח שאילתות על מנועי ה-TTS הזמינים באמצעות getEngines(). השיטה הזו מחזירה רשימה של TextToSpeech.EngineInfo אובייקטים, כולל מטא-נתונים כמו סמל, תווית ושם חבילה.

יצירת מנועים להמרת טקסט לדיבור (TTS)

בעבר, מנועים בהתאמה אישית דרשו לבנות את המנוע באמצעות כותרת מקורית לא מתועדת חדש. ב-Android 4.0 יש קבוצה מלאה של ממשקי API של מסגרות ליצירת מנועי TTS.

ההגדרה הבסיסית מחייבת הטמעה של TextToSpeechService שתגיב לכוונה INTENT_ACTION_TTS_SERVICE. העבודה הראשית במנוע TTS מתרחשת במהלך הקריאה החוזרת של onSynthesizeText() בשירות שאורכו TextToSpeechService. המערכת מעבירה לשיטה הזו שני אובייקטים:

  • SynthesisRequest: השדה הזה מכיל נתונים שונים, כולל הטקסט שרוצים לסנתז, האזור, קצב הדיבור וטון הקול.
  • SynthesisCallback: זהו הממשק שבו מנוע ה-TTS מעביר את נתוני הדיבור שנוצרו כסטרימינג של אודיו. קודם כל המנוע צריך לקרוא ל-start() כדי לציין שהמנוע מוכן לספק את האודיו, ואז קוראים ל-audioAvailable(), ומעבירים אליו את נתוני האודיו במאגר נתונים זמני של בייטים. אחרי שהמנוע מעביר את כל האודיו דרך מאגר נתונים זמני, צריך לבצע קריאה אל done().

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

לדוגמה, למנוע TTS שמשתמש בממשקי ה-API החדשים, באפליקציה לדוגמה Text to Speech Engine.

שימוש ברשת

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

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

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

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

חשוב לזכור ש-getBackgroundDataSetting() הוצאה משימוש ותמיד מחזירה את הערך true. במקום זאת, צריך להשתמש ב-getActiveNetworkInfo(). לפני שמנסים לבצע עסקאות ברשת, תמיד צריך להפעיל את getActiveNetworkInfo() כדי לקבל את הערך של NetworkInfo שמייצג את הרשת הנוכחית, ולבצע שאילתה ל-isConnected() כדי לבדוק אם יש למכשיר חיבור. לאחר מכן אפשר לבדוק מאפייני חיבור אחרים, למשל אם המכשיר בנדידה או בחיבור לרשת Wi-Fi.

Enterprise

מערכת Android 4.0 מרחיבה את היכולות של אפליקציות ארגוניות באמצעות התכונות הבאות.

שירותי VPN

הגרסה החדשה של VpnService מאפשרת לאפליקציות ליצור VPN משלהן (וירטואלי רשת פרטית), פועלת בתור Service. שירות VPN יוצר ממשק לרשת וירטואלית עם כתובת וכללי ניתוב משלו, ומבצע את כל הקריאה והכתיבה באמצעות מתאר קובץ.

כדי ליצור שירות VPN, משתמשים ב-VpnService.Builder, שמאפשר לציין את כתובת הרשת, שרת ה-DNS, מסלול הרשת ועוד. בסיום, אפשר ליצור את הממשק באמצעות קריאה ל-establish(), שמחזירה ParcelFileDescriptor.

מכיוון ששירות VPN יכול ליירט מנות, יש לכך השלכות על האבטחה. לכן, אם להטמיע את VpnService, ואז השירות חייב לדרוש את המאפיין BIND_VPN_SERVICE כדי להבטיח שרק המערכת תוכל לקשר אליו (רק שהמערכת קיבלה את ההרשאה הזו – אפליקציות לא יכולות לבקש אותה). כדי להשתמש בשירות ה-VPN: המשתמשים חייבים להפעיל אותו באופן ידני בהגדרות המערכת.

מדיניות המכשיר

אפליקציות שמנהלות את הגבלות המכשיר יכולות עכשיו להשבית את המצלמה באמצעות setCameraDisabled() והמאפיין USES_POLICY_DISABLE_CAMERA (שמיושמים באמצעות רכיב <disable-camera /> בקובץ התצורה של המדיניות).

ניהול אישורים

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

חיישני המכשיר

שני סוגים חדשים של חיישנים נוספו ב-Android 4.0:

  • TYPE_AMBIENT_TEMPERATURE: חיישן טמפרטורה שמספק את הטמפרטורה הסביבתית (בטמפרטורת החדר) במעלות צלזיוס.
  • TYPE_RELATIVE_HUMIDITY: חיישן לחות שמספק את הלחות היחסית בסביבה (בחדר) כאחוז.

אם במכשיר יש גם חיישנים של TYPE_AMBIENT_TEMPERATURE וגם TYPE_RELATIVE_HUMIDITY, אפשר להשתמש בהם כדי לחשב את נקודת הטל ואת הלחות המוחלטת.

חיישן הטמפרטורה הקודם, TYPE_TEMPERATURE, הוצא משימוש. עליך להשתמש בחיישן TYPE_AMBIENT_TEMPERATURE במקום זאת.

בנוסף, שלושת החיישנים הסינתטיים של Android שופרו באופן משמעותי, ועכשיו הם נמוכים יותר זמן אחזור ופלט חלק יותר. החיישנים האלה כוללים את חיישן הכבידה (TYPE_GRAVITY), חיישן וקטור הסיבוב (TYPE_ROTATION_VECTOR) וחיישן ההאצה הליניארית (TYPE_LINEAR_ACCELERATION). החיישנים המשופרים מסתמכים על חיישן הג'ירוסקופ כדי לשפר את הפלט שלהם, ולכן החיישנים מופיעים רק במכשירים שיש בהם ג'ירוסקופ.

סרגל פעולות

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

סרגל הפעולות של פיצול

אם סרגל הפעולות כולל מספר פעולות לביצוע, לא כולן יופיעו בסרגל הפעולות מסך צר, כך שהמערכת תציב יותר מהם בתפריט האפשרויות הנוספות. עם זאת, ב-Android 4.0 אפשר להפעיל 'סרגל פעולות מפוצל' כדי שפריטי פעולה נוספים יוכלו להופיע במסך בסרגל נפרד בתחתית המסך. כדי להפעיל את סרגל הפעולות המפוצל, צריך להוסיף את android:uiOptions עם "splitActionBarWhenNarrow" לאחת מהאפשרויות <application> תג או תגי <activity> נפרדים בקובץ המניפסט. כשהתכונה הזו מופעלת, המערכת מוסיפה סרגל נוסף בתחתית המסך לכל פעולות האפשריות כשהמסך צר (אף פעולה לא תופיע בסרגל הפעולות הראשי).

אם אתם רוצים להשתמש בכרטיסי הניווט שסופקו על ידי ממשקי ה-API של ActionBar.Tab, אבל אתם לא צריכים את סרגל הפעולות הראשי בחלק העליון (אתם רוצים שרק הכרטיסיות יופיעו בחלק העליון), צריך להפעיל את סרגל הפעולות המפוצל כמו שמתואר למעלה, וגם להפעיל את setDisplayShowHomeEnabled(false) כדי להשבית את סמל האפליקציה בסרגל הפעולות. אם לא תישאר שום פעולה בסרגל הפעולות הראשי, הוא ייעלם. כל מה שיישאר הם כרטיסיות הניווט בחלק העליון ופריטי הפעולות לביצוע בחלק התחתון של המסך.

סגנונות של סרגל הפעולות

אם רוצים להחיל עיצוב מותאם אישית על סרגל הפעולות, אפשר להשתמש במאפייני הסגנון החדשים backgroundStacked ו-backgroundSplit כדי להחיל drawable או צבע של רקע על הסרגל הממוזער ועל הסרגל המפוצל, בהתאמה. אפשר להגדיר את הסגנונות האלה גם בכתובת עם setStackedBackgroundDrawable() ו-setSplitBackgroundDrawable().

ספק הפעולות

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

לדוגמה, ShareActionProvider הוא תוסף של ActionProvider שמאפשר להשתמש ב'שיתוף' פעולה מסרגל הפעולות. במקום להשתמש ב- פעולה מסורתית שמפעילה את ה-Intent ACTION_SEND, אפשר להשתמש בספק הפעולה הזה כדי להציג תצוגת פעולות עם רשימה נפתחת של אפליקציות שמטפלות את הכוונה ACTION_SEND. כשהמשתמש בוחר אפליקציה לשימוש לביצוע הפעולה, ShareActionProvider זוכר את הבחירה הזו ומספק בתצוגת הפעולה כדי לאפשר גישה מהירה יותר לשיתוף עם אותה אפליקציה.

כדי להצהיר על ספק פעולה לפריט פעולה, צריך לכלול את המאפיין android:actionProviderClass באלמנט <item> של תפריט האפשרויות של הפעילות, עם שם הכיתה של ספק הפעולה בתור הערך. לדוגמה:

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

בשיטת ה-callback‏ onCreateOptionsMenu() של הפעילות, מאחזרים מופע של ספק הפעולה מפריט התפריט ומגדירים את הכוונה:

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

דוגמה לשימוש ב-ShareActionProvider מופיעה ב-ActionBarShareActionProviderActivity ב-ApiDemos.

תצוגת פעולה שניתן לכווץ

פעולות לביצוע שמספקות תצוגת פעולה יכולות עכשיו לעבור בין מצב תצוגת הפעולה על מצב מסורתי של פעולה לביצוע. בעבר, רק הרכיב SearchView תמך באפשרות לכווץ אותו כשמשתמשים בו בתצוגת פעולה. עכשיו אפשר להוסיף תצוגת פעולה לכל פריט פעולה ולעבור בין המצב המורחב (תצוגת הפעולה גלויה) למצב המכווץ (פריט הפעולה גלוי).

כדי להצהיר שאפשר לכווץ פריט פעולה שמכיל תצוגת פעולה, צריך לכלול את הדגל “collapseActionView" במאפיין android:showAsAction של האלמנט <item> בקובץ ה-XML של התפריט.

כדי לקבל קריאות חוזרות (callback) כשתצוגת פעולה עוברת בין תצוגה מורחבת למכווצת, צריך לרשום של MenuItem.OnActionExpandListener עם MenuItem המתאים, באמצעות הפקודה setOnActionExpandListener(). בדרך כלל, צריך לעשות זאת במהלך קריאת החזרה (callback) של onCreateOptionsMenu().

כדי לשלוט בתצוגת פעולה שאפשר לכווץ, אפשר להפעיל את collapseActionView() ואת expandActionView() MenuItem בהתאמה.

כשיוצרים תצוגה של פעולה מותאמת אישית, אפשר גם להטמיע את ממשק CollapsibleActionView החדש כדי לקבל קריאות חוזרות (callback) כשהתצוגה מורחבת במצב מכווץ.

ממשקי API אחרים לסרגל הפעולות

  • setHomeButtonEnabled() מאפשר לך לציין אם הסמל/הלוגו פועלים כלחצן לניווט לדף הבית או למעלה (הזינו את המילה 'TRUE' כדי שיתנהג כמו לחצן).
  • setIcon() ו-setLogo() מאפשרים להגדיר את הסמל או הלוגו של סרגל הפעולות בזמן הריצה.
  • Fragment.setMenuVisibility() מאפשר לך להפעיל או להשבית את הרשאות הגישה לאפשרויות בתפריט האפשרויות שהוצהרו על ידי המקטע. האפשרות הזו שימושית אם הקטע נוסף לפעילות אבל הוא לא גלוי, ולכן צריך להסתיר את פריטי התפריט.
  • FragmentManager.invalidateOptionsMenu() מאפשרת לבטל את התוקף של תפריט אפשרויות הפעילות במהלך מצבים שונים של מחזור החיים של המקטע שבהם שימוש בשיטה המקבילה מ-Activity לא יהיה זמין.

ממשק משתמש ותצוגות

מערכת Android 4.0 כוללת מגוון תצוגות חדשות ורכיבים אחרים בממשק המשתמש.

פריסת רשת

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

ראו ApiDemos לדגימות באמצעות GridLayout.

תצוגת מרקם

TextureView היא תצוגה חדשה שמאפשרת להציג מקור תוכן, כמו כסרטון או כתמונת OpenGL. למרות הדמיון ל-SurfaceView, הערך TextureView הוא ייחודי בכך שהוא מתנהג כמו תצוגה רגילה, במקום ליצור חלון נפרד, כך שאפשר להתייחס אליו כמו לכל אובייקט View אחר. לדוגמה, אפשר לבצע שינויים בשינויים, להנפיש אותם באמצעות ViewPropertyAnimator, או לכוונן את השקיפות שלו באמצעות setAlpha().

חשוב לזכור ש-TextureView פועל רק בחלון עם שיפור מהירות באמצעות חומרה.

מידע נוסף זמין במסמכי העזרה של TextureView.

החלפת ווידג'ט

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

אפשר להשתמש במאפיינים android:textOn ו-android:textOff כדי לציין את הטקסט יופיע במתג כאשר ההגדרה מופעלת וכבויה. המאפיין android:text מאפשר גם להציב תווית לצד המתג.

לדוגמה של שימוש במתגים, ראו את קובץ הפריסה switches.xml ואת הפעילות Switches המתאימה.

ב-Android 3.0 הושקה גרסה של PopupMenu שמאפשרת ליצור תפריטי הקשר קצרים שקופצים בנקודת עוגן שציינתם (בדרך כלל בנקודה של הפריט שנבחר). Android 4.0 מורחב PopupMenu עם כמה תכונות שימושיות:

  • עכשיו אפשר בקלות להרחיב את התוכן של תפריט קופץ ממשאב תפריט ב-XML באמצעות inflate(), ולהעביר לו את מזהה משאב התפריט.
  • עכשיו אפשר גם ליצור PopupMenu.OnDismissListener שמקבל קריאה חוזרת (callback) כשהתפריט נסגר.

העדפות

שיעור מופשט חדש ב-TwoStatePreference משמש כבסיס העדפות שמאפשרות בחירה בשני מצבים. הגרסה החדשה של SwitchPreference היא תוסף של TwoStatePreference שמספק את הווידג'ט Switch תצוגת העדפה שמאפשרת למשתמשים להפעיל או להשבית הגדרה מבלי לפתוח מסך ההעדפות או תיבת דו-שיח. לדוגמה, האפליקציה 'הגדרות' משתמשת ב-SwitchPreference עבור הגדרות ה-Wi-Fi וה-Bluetooth.

עיצובים של המערכת

עיצוב ברירת המחדל של כל האפליקציות שמטרגטות את Android 4.0 (על ידי הגדרת targetSdkVersion או minSdkVersion ל-“14" ואילך) הוא עכשיו 'עיצוב ברירת המחדל של המכשיר': Theme.DeviceDefault. יכול להיות שזה יהיה עיצוב Holo כהה או עיצוב כהה אחר שמוגדר במכשיר הספציפי.

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

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

לחצן של תפריט האפשרויות

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

כדי ליהנות מחוויית המשתמש הטובה ביותר, אפליקציות חדשות ומעודכנות צריכות להשתמש במקום זאת בActionBar כדי לתת גישה לאפשרויות בתפריט ולהגדיר את targetSdkVersion לערך "14" כדי לנצל את היתרונות של התנהגויות ברירת המחדל העדכניות של framework.

אמצעי בקרה להרשאות הגישה לממשק המשתמש של המערכת

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

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

  • הדגל SYSTEM_UI_FLAG_LOW_PROFILE מחליף את הדגל STATUS_BAR_HIDDEN. כשהדגל הזה מוגדר, הוא מפעיל את המצב 'פרופיל נמוך' בסרגל המערכת או בסרגל הניווט. לחצני הניווט מעומעמים ורכיבים אחרים בסרגל המערכת גם מוסתרים. מפעיל כך אפשר ליצור משחקים סוחפים יותר בלי הסחות דעת לניווט במערכת. הלחצנים.
  • הדגל SYSTEM_UI_FLAG_VISIBLE מחליף את הדגל STATUS_BAR_VISIBLE כדי לבקש שהסרגל המערכת או סרגל הניווט יהיו גלויים.
  • השדה SYSTEM_UI_FLAG_HIDE_NAVIGATION הוא דגל חדש שמבקש שסרגל הניווט מוסתר לגמרי. לתשומת ליבך: האפשרות הזו פועלת רק בסרגל הניווט. בטלפונים מסוימים, הוא לא מסתיר את סרגל המערכת בטאבלטים). הניווט העמודה תחזור לתצוגה ברגע שהמערכת מקבלת קלט ממשתמשים. לכן המצב הזה מועיל בעיקר להפעלת וידאו או במקרים אחרים שבהם צריך את כל המסך אבל הקלט של המשתמשים לא נדרש.

אפשר להגדיר כל אחד מהדגלים האלה בסרגל המערכת ובסרגל הניווט באמצעות קריאה ל-setSystemUiVisibility() בכל תצוגה בפעילות. מנהל החלונות משלב (OR-together) את כל הדגלים מכל התצוגות בחלון ומחילה אותם על ממשק המשתמש של המערכת כל עוד החלון נמצא ב-input focus. כשהמערכת מאבדת קלט מהחלון (המשתמש מנווט אל מחוץ לאפליקציה, או שמופיעה תיבת דו-שיח), הדגלים יפסיקו לפעול. באופן דומה, אם תסירו את התצוגות האלה מהיררכיית התצוגות, הדגלים שלהן לא יחולו יותר.

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

כדאי לעיין בכיתה OverscanActivity כדי לראות הדגמה של אפשרויות שונות של ממשק המשתמש של המערכת.

מסגרת קלט

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

אירועי העברת העכבר

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

כדי לקבל אירועי מעברי עכבר בתצוגה, מטמיעים את View.OnHoverListener ומרשמים אותו באמצעות setOnHoverListener(). כשמתרחש אירוע של מעקב אחר העכבר בתצוגה, ה-listener מקבל קריאה ל-onHover(), עם הפרטים של View שקיבל את האירוע ושל MotionEvent שמתאר את סוג אירוע המעקב אחר העכבר שהתרחש. אירוע ההעברה מעל יכול להיות אחד מהאירועים הבאים:

הפונקציה View.OnHoverListener צריכה להחזיר את הערך true מ-onHover() אם היא מטפלת באירוע ההעברה עם העכבר מעל. אם ה-listener מחזיר את הערך false, ואירוע העברת העכבר יישלח לתצוגת ההורה כרגיל.

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

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

אירועים של לחצן עכבר ועט

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

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

כדי להבדיל בין קלט באמצעות אצבע, עכבר, עט או מחק, האפליקציה יכולה לשלוח שאילתה לגבי 'סוג הכלי' שמשויך לכל סמן ב-MotionEvent באמצעות getToolType(). סוגי הכלים שמוגדרים כרגע הם: TOOL_TYPE_UNKNOWN, TOOL_TYPE_FINGER, TOOL_TYPE_MOUSE, TOOL_TYPE_STYLUS ו-TOOL_TYPE_ERASER. על ידי שאילתה על סוג הכלי, האפליקציה יכול לטפל בקלט סטיילוס בדרכים שונות מהקלט באמצעות האצבע או העכבר.

האפליקציה יכולה גם לבצע שאילתה על אילו לחצני עכבר או סטיילוס לוחצים על ידי שליחת שאילתה על הלחצן " מצב" של MotionEvent באמצעות getButtonState(). מצבי הלחצן שמוגדרים כרגע הם: BUTTON_PRIMARY,‏ BUTTON_SECONDARY,‏ BUTTON_TERTIARY,‏ BUTTON_BACK ו-BUTTON_FORWARD. לנוחיותכם, לחצני העכבר קדימה ואחורה ממופה באופן אוטומטי למפתחות KEYCODE_BACK ו-KEYCODE_FORWARD. האפליקציה יכולה לטפל במפתחות האלה כדי לתמוך בניווט קדימה ואחורה באמצעות לחצני העכבר.

בנוסף למדידה מדויקת של המיקום והלחץ של איש קשר, חלק מקלט הסטיילוס במכשירים האלה גם מדווח המרחק בין קצה הסטיילוס לדיגיטלי, זווית הטיית הסטיילוס. ואת זווית הכיוון של הסטיילוס. האפליקציה יכולה לשלוח שאילתה לגבי המידע הזה באמצעות getAxisValue() עם קודי הצירים AXIS_DISTANCE,‏ AXIS_TILT ו-AXIS_ORIENTATION.

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

מאפיינים

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

לדוגמה, אם רוצים להגדיר את הערך של השדה bar באובייקט foo, צריך עשו זאת בעבר:

Kotlin

foo.bar = value

Java

foo.bar = value;

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

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

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

באמצעות הכיתה Property, אפשר להצהיר על אובייקט Property‏ BAR בכיתה Foo כדי להגדיר את השדה במופע foo של הכיתה Foo באופן הבא:

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

הכיתה View משתמשת עכשיו בכיתה Property כדי מאפשרות להגדיר שדות שונים, כמו טרנספורמציה של מאפיינים שנוספו ב-Android 3.0 (ROTATION, ROTATION_X, TRANSLATION_X וכו').

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

שיפור המהירות באמצעות חומרה

החל מ-Android 4.0, שיפור המהירות באמצעות חומרה בכל החלונות מופעל כברירת מחדל אם האפליקציה הגדירה targetSdkVersion או minSdkVersion עד “14" ומעלה. בדרך כלל, האצת החומרה מובילה לאנימציות חלקות יותר, לגלילה חלקה יותר ולביצועים טובים יותר באופן כללי, וגם לתגובה מהירה יותר לאינטראקציות של המשתמשים.

אם צריך, אפשר להשבית ידנית את שיפור המהירות באמצעות חומרה באמצעות המאפיין hardwareAccelerated לרכיבים ספציפיים מסוג <activity> או באמצעות הרכיב <application>. לחלופין, אפשר להשבית את האצת החומרה בתצוגות ספציפיות באמצעות קריאה ל-setLayerType(LAYER_TYPE_SOFTWARE).

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

שינויים ב-JNI

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

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

השינוי בהטמעת ה-JNI משפיע רק על אפליקציות שמטרגטות ל-Android 4.0 על ידי הגדרה של targetSdkVersion או minSdkVersion עד “14" ואילך. אם הגדרתם את המאפיינים האלה לערך נמוך יותר, קובצי העזר המקומיים של JNI מתנהגים בדיוק כמו בגרסאות הקודמות.

WebKit

  • WebKit עודכן לגרסה 534.30
  • תמיכה בגופנים הודיים (דנאוואגרי, בנגלית וטמילית, כולל תמיכה בתווים מורכבים שנדרשים לשילוב גליפים) ב-WebView ובדפדפן המובנה
  • תמיכה בגופנים אתיופיים, גיאורגיים וארמניים בWebView דפדפן מובנה
  • התמיכה ב-WebDriver מאפשרת לכם לבדוק בקלות רבה יותר אפליקציות שמשתמשות ב-WebView

דפדפן Android

יישום הדפדפן מוסיף את התכונות הבאות לתמיכה באפליקציות אינטרנט:

הרשאות

אלו ההרשאות החדשות:

תכונות המכשיר

אלה התכונות החדשות במכשיר:

  • FEATURE_WIFI_DIRECT: הצהרה שהבקשה משתמשת Wi-Fi לתקשורת מקצה לקצה.

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

ממשקי API קודמים

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

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

Android 3.0
  • Fragment: רכיב מסגרת שמאפשר להפריד בין רכיבים נפרדים של פעילות למודולים עצמאיים שמגדירים את ממשק המשתמש ומחזור החיים שלהם. לצפייה המדריך למפתחים של מקטעים.
  • ActionBar: תחליף לסרגל הכותרת המסורתי בחלק העליון של חלון הפעילות. הוא כולל את הלוגו של האפליקציה בפינה הימנית ומציע ממשק חדש לפריטי התפריט. אפשר לעיין במדריך למפתחים בנושא סרגל הפעולות.
  • Loader: רכיב framework שמאפשר גישה אסינכרונית טעינת נתונים בשילוב עם רכיבי ממשק משתמש כדי לטעון נתונים באופן דינמי מבלי לחסום את של ה-thread הראשי. לצפייה מדריך למפתחים של Loaders
  • לוח העריכה של המערכת: אפליקציות יכולות להעתיק ולהדביק נתונים (מעבר לטקסט בלבד) אל וממנו את הלוח ברמת המערכת. נתונים חתוכים יכולים להיות טקסט פשוט, URI או כוונה. אפשר לעיין במדריך למפתחים בנושא העתקה והדבקה.
  • גרירה ושחרור: קבוצה של ממשקי API מובנים בתוך מסגרת התצוגה, המאפשרים גרירה ושחרור ב-AI. לצפייה מדריך למפתחים בנושא גרירה ושחרור.
  • מסגרת אנימציה חדשה שמאפשרת הנפשה של מאפיינים שרירותיים של כל (תצוגה, שרטוט, מקטע, אובייקט או כל דבר אחר) ולהגדיר היבטי אנימציה כמו כמו משך זמן, אינטרפולציה, חזרה ועוד. בעזרת המסגרת החדשה, קל יותר מאי פעם ליצור אנימציות ב-Android. למידע נוסף, ראו המדריך למפתחים בנושא אנימציה של נכסים.
  • גרפיקה ומנוע מחשוב של RenderScript: RenderScript מציע תלת-ממד בעל ביצועים גבוהים. עיבוד גרפיקה ו-Compute API ברמת המקור, שאותם כותבים בתקן C99 (C99), מספק את רמת הביצועים שאתם מצפים לקבל מסביבה מקורית, תוך שמירה על ניידות בכמה מעבדי CPU ומעבדי GPU. לצפייה מפתח של RenderScript מותאמת אישית.
  • גרפיקה דו-ממדית עם האצת חומרה: כעת ניתן להפעיל את מעבד OpenGL עבור על ידי הגדרה של {android:hardwareAccelerated="true"} ב-<application> של רכיב המניפסט אלמנט או עבור יחיד <activity> רכיבים. התוצאה של התהליך הזה באנימציות חלקות יותר, גלילה חלקה יותר וביצועים טובים יותר באופן כללי ותגובה טובה יותר למשתמש אינטראקציה חוזרת.

    הערה: אם מגדירים את minSdkVersion או את targetSdkVersion של האפליקציה לערך "14" ומעלה, שיפור המהירות באמצעות חומרה מופעל כברירת מחדל.

  • ועוד הרבה יותר. מידע נוסף זמין בהערות לגבי פלטפורמת Android 3.0.
Android 3.1
  • ממשקי USB API: ממשקי API חדשים וחזקים לשילוב ציוד היקפי מחובר עם אפליקציות ל-Android. ממשקי ה-API מבוססים על שירותים וסטאק USB שמובנים בפלטפורמה, כולל תמיכה באינטראקציות עם מארחי USB ועם מכשירים. כדאי לעיין במדריך למפתחים של מארח ואביזרים בחיבור USB.
  • ממשקי API של MTP/PTP: אפליקציות יכולות לקיים אינטראקציה ישירה עם מצלמות מחוברות ועם מכשירי PTP אחרים כדי לקבל התראות כשהמכשירים מחוברים ומנותקים, לנהל את הקבצים ואת האחסון במכשירים האלה ולהעביר קבצים ומטא-נתונים אליהם ומהם. ממשק ה-API של MTP מטמיע את ה-PTP (Picture Transfer Protocol) משנה את מפרט ה-MTP (פרוטוקול העברת מדיה). אפשר לעיין במסמכי התיעוד של android.mtp.
  • ממשקי API של RTP: Android חושף ממשק API למחסנית ה-RTP (Real-time Transport Protocol) המובנית שלו, שבאמצעותו אפליקציות יכולות לנהל סטרימינג של נתונים על פי דרישה או סטרימינג אינטראקטיבי. באופן ספציפי, אפליקציות שמספקות VOIP, לחיצה לדיבור, שיתוף מסך וסטרימינג של אודיו יכולות להשתמש ב-API כדי להתחיל סשנים ולשלוח או לקבל מקורות נתונים דרך כל רשת זמינה. לעיון במסמכי התיעוד של android.net.rtp.
  • תמיכה בלחצני ג'ויסטיק ובכניסות תנועה כלליות אחרות.
  • בהערות לגבי פלטפורמת Android 3.1 מפורטים ממשקי API חדשים רבים נוספים.
Android 3.2
  • מסכים חדשים תומכים בממשקי API שמעניקים לך שליטה רבה יותר על אופן הפעולה של האפליקציות יוצגו במסכים בגדלים שונים. ה-API מרחיב את מודל התמיכה הקיים במסכים ומאפשר לכם לטרגט במדויק טווחים ספציפיים של גדלי מסך לפי מאפיינים, שנמדדים ביחידות פיקסלים שלא תלויות בצפיפות (כמו 600dp או 720dp רוחב), ולא לפי גדלי המסך הכללים (כמו גדול או גדול במיוחד). לדוגמה, השלב הזה חשוב כדי לעזור לך הבחינו בין 5 אינץ' ומכשיר בגודל 7 אינץ' שבדרך כלל מסווגת בתור 'large' מסכים. לעיון בפוסט בבלוג, כלים חדשים לניהול גדלים של מסכים.
  • ערכי קבועים חדשים ל-<uses-feature> כדי להצהיר על דרישות לכיוון המסך – לרוחב או לאורך.
  • גודל המסך של המכשיר ההגדרות האישיות משתנות עכשיו בזמן כיוון המסך שינוי. אם האפליקציה שלך מטרגטת רמת API 13 ומעלה, עליך לטפל ב"screenSize" של ההגדרה האישית אם ברצונך לטפל גם בשינוי ההגדרה של "orientation". צפייה לקבלת מידע נוסף, android:configChanges.
  • מידע נוסף זמין בפלטפורמת Android 3.2 הערות לגבי ממשקי API חדשים אחרים.

רמת ה-API

ל-Android 4.0 API מוקצה מספר שלם מזהה 14 שמאוחסן במערכת עצמה. המזהה הזה, שנקרא 'רמת ה-API', מאפשר למערכת לקבוע בצורה נכונה אם אפליקציה תואמת למערכת, לפני התקנת האפליקציה.

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

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