ממשקי API של Android 4.1

רמת API: 16

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

מפתחי אפליקציות יכולים למצוא את Android 4.1 ב-SDK Manager כקובץ אימג' של מערכת שאפשר להריץ במהדמ של Android וכפלטפורמת SDK שאפשר לבנות לפיה את האפליקציה. מומלץ להוריד את קובץ האימג' ואת הפלטפורמה בהקדם האפשרי כדי לבנות ולבדוק את האפליקציה ב-Android 4.1.

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

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

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

רכיבי אפליקציה

שירותים מבודדים

כשמציינים את הערך android:isolatedProcess="true" בתג <service>, Service יופעל בתהליך מבודד של User-ID שאין לו הרשאות משלו.

ניהול הזיכרון

קבועים חדשים של ComponentCallbacks2, כמו TRIM_MEMORY_RUNNING_LOW ו-TRIM_MEMORY_RUNNING_CRITICAL, מספקים לתהליכים בחזית מידע נוסף על מצב הזיכרון לפני שהמערכת קוראת ל-onLowMemory().

השיטה החדשה getMyMemoryState(ActivityManager.RunningAppProcessInfo) מאפשרת לאחזר את מצב הזיכרון הכללי.

ספקי תוכן

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

טפטים מונפשים

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

כדי להפעיל את הכלי לבחירת טפט דינמי, קוראים ל-startActivity() עם Intent באמצעות ACTION_CHANGE_LIVE_WALLPAPER ופריט נוסף שמציין את הטפט הדינמי ComponentName כמחרוזת ב-EXTRA_LIVE_WALLPAPER_COMPONENT.

ניווט במקבץ האפליקציות

ב-Android 4.1 קל הרבה יותר להטמיע את דפוסי העיצוב המתאימים לניווט למעלה. כל מה שצריך לעשות הוא להוסיף את android:parentActivityName לכל רכיב <activity> בקובץ המניפסט. המערכת משתמשת במידע הזה כדי לפתוח את הפעילות המתאימה כשהמשתמש לוחץ על הלחצן למעלה בסרגל הפעולות (וגם מסיים את הפעילות הנוכחית). לכן, אם מגדירים את android:parentActivityName לכל פעילות, לא צריך את השיטה onOptionsItemSelected() כדי לטפל באירועי קליקים על סמל האפליקציה בסרגל הפעולות – עכשיו המערכת מטפלת באירוע הזה וממשיכה או יוצרת את הפעילות המתאימה.

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

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

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

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

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

onNavigateUp()
אפשר לשנות את ההגדרה הזו כדי לבצע פעולה מותאמת אישית כשהמשתמש לוחץ על הלחצן 'למעלה'.
navigateUpTo(Intent)
קוראים ל-method הזה כדי לסיים את הפעילות הנוכחית ולעבור לפעילות שצוינה ב-Intent שסופק. אם הפעילות קיימת ב-back stack אבל היא לא ההורה הקרוב ביותר, כל הפעילויות האחרות שבין הפעילות הנוכחית לפעילות שצוינה ב-intent מסתיימות גם הן.
getParentActivityIntent()
קוראים ל-method הזה כדי לקבל את Intent שיפעיל את ההורה הלוגי של הפעילות הנוכחית.
shouldUpRecreateTask(Intent)
קוראים ל-method הזה כדי לבדוק אם צריך ליצור סטאק אחורה סינתטי כדי לנווט למעלה. הפונקציה מחזירה את הערך true אם צריך ליצור סטאק סינתטי, ואת הערך false אם הסטאק המתאים כבר קיים.
finishAffinity()
קוראים ל-method הזה כדי לסיים את הפעילות הנוכחית ואת כל הפעילויות ההורה עם אותו משימות משיכה שמקושרות לפעילות הנוכחית. אם מבטלים את ברירת המחדל של התנהגויות כמו onNavigateUp(), צריך לקרוא ל-method הזה כשיוצרים סטאק אחורה סינתטי במהלך ניווט למעלה.
onCreateNavigateUpTaskStack
אפשר לשנות את הערך הזה אם אתם צריכים לשלוט באופן מלא באופן שבו יצירת סטאק המשימות הסינתטיות. אם רוצים פשוט להוסיף נתונים נוספים לכוונות של סטאק החזרה, צריך לשנות את onPrepareNavigateUpTaskStack()
במקום זאת

עם זאת, ברוב האפליקציות אין צורך להשתמש בממשקי ה-API האלה או להטמיע את onPrepareNavigateUpTaskStack(), אלא אפשר להשיג את ההתנהגות הנכונה פשוט על ידי הוספת android:parentActivityName לכל רכיב <activity>.

מולטימדיה

קודקים של מדיה

הכיתה MediaCodec מספקת גישה לקודקים של מדיה ברמה נמוכה, לצורך קידוד ופענוח של המדיה. אפשר ליצור מופע של MediaCodec על ידי קריאה ל-createEncoderByType() כדי לקודד מדיה, או לקרוא ל-createDecoderByType() כדי לפענח מדיה. כל אחת מהשיטות האלה משתמשת בסוג MIME לסוג המדיה שרוצים לקודד או לפענח, למשל "video/3gpp" או "audio/vorbis".

אחרי שיוצרים מופע של MediaCodec, אפשר להפעיל את configure() כדי לציין מאפיינים כמו פורמט המדיה או אם התוכן מוצפן או לא.

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

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

באופן דומה, כדי לקבל את המיקום של ByteBuffer במערך, שבו תקבלו את התוצאות, צריך להפעיל את הפונקציה dequeueOutputBuffer(). אחרי שקוראים את הפלט של ByteBuffer, משחררים את הבעלות על ידי קריאה ל-releaseOutputBuffer().

אפשר לטפל בנתוני מדיה מוצפנים ברכיבי ה-Codec על ידי קריאה ל-queueSecureInputBuffer() בשילוב עם ממשקי ה-API של MediaCrypto, במקום לקצב הרגיל של queueInputBuffer().

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

הקלטת אודיו בסימון

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

טראקים של טקסט מתוזמן

MediaPlayer מטפל עכשיו בטראקים של טקסט בפורמט In-band וגם בטראקים של טקסט מחוץ למסגרת. טראקים של טקסט מסוג In-band מגיעים כטראק טקסט בתוך מקור מדיה MP4 או 3GPP. אפשר להוסיף טראקים של טקסט מחוץ למסגרת בתור מקור טקסט חיצוני באמצעות method addTimedTextSource(). אחרי שמוסיפים את כל המקורות החיצוניים של טראקים של טקסט, צריך לבצע קריאה ל-getTrackInfo() כדי לקבל את הרשימה המחודשת של כל הטראקים הזמינים במקור הנתונים.

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

כדי לקבל התראה כשפס הטקסט מוכן להפעלה, מטמיעים את הממשק MediaPlayer.OnTimedTextListener ומעבירים אותו ל-setOnTimedTextListener().

אפקטי אודיו

מעכשיו, בכיתה AudioEffect יש תמיכה בסוגי עיבוד אודיו נוספים לפני הצילום:

  • הכלי לביטול ההד של האודיו (AEC) עם AcousticEchoCanceler מסיר את התרומה של האות שהתקבל מהצד הרחוק מאות האודיו שצולם.
  • בקרת בהירות אוטומטית (AGC) עם AutomaticGainControl מנרמלת באופן אוטומטי את הפלט של האות שנקלט.
  • סינון הרעשים (NS) עם NoiseSuppressor מסיר את רעשי הרקע מהאות שנקלט.

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

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

הפעלה ללא הפסקות

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

נתב מדיה. ממשקי ה-API החדשים MediaRouter‏, MediaRouteActionProvider ו-MediaRouteButton מספקים מנגנונים סטנדרטיים וממשק משתמש לבחירת המיקום שבו רוצים להפעיל את המדיה.

מצלמה

תנועה של המיקוד האוטומטי

בממשק החדש Camera.AutoFocusMoveCallback אפשר להאזין לשינויים בתנועת המיקוד האוטומטי. אפשר לרשום את הממשק שלכם ב-setAutoFocusMoveCallback(). לאחר מכן, כשהמצלמה במצב מיקוד אוטומטי רציף (FOCUS_MODE_CONTINUOUS_VIDEO או FOCUS_MODE_CONTINUOUS_PICTURE), מקבלים קריאה ל-onAutoFocusMoving(), שמציינת אם המיקוד האוטומטי התחיל לנוע או הפסיק לזוז.

צלילי מצלמה

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

כדי להשמיע צליל, פשוט יוצרים אובייקט MediaActionSound, קוראים ל-load() כדי לטעון מראש את הצליל הרצוי, ובזמן המתאים קוראים ל-play().

קישוריות

Android Beam

Android BeamTM תומך עכשיו בהעברות מטענים גדולים באמצעות Bluetooth. כשמגדירים את הנתונים להעברה באמצעות השיטה החדשה setBeamPushUris() או באמצעות ממשק ה-callback החדש NfcAdapter.CreateBeamUrisCallback, Android מעבירה את העברת הנתונים ל-Bluetooth או לכלי העברה חלופי אחר כדי להגיע למהירויות העברה גבוהות יותר. היא שימושית במיוחד למטענים ייעודיים (payloads) גדולים כמו קובצי תמונה ואודיו, ואין צורך בהתאמה גלויה בין המכשירים. האפליקציה לא דורשת פעולות נוספות כדי לאפשר העברות באמצעות Bluetooth.

השיטה setBeamPushUris() לוקחת מערך של אובייקטים Uri שמציינים את הנתונים שרוצים להעביר מהאפליקציה. לחלופין, אפשר להטמיע את הממשק NfcAdapter.CreateBeamUrisCallback, שאפשר להגדיר לפעילות על ידי קריאה ל-setBeamPushUrisCallback().

כשמשתמשים בממשק ה-callback, המערכת קוראת לשיטה createBeamUris() של הממשק כשהמשתמש מבצע שיתוף באמצעות Android Beam, כדי שתוכלו להגדיר את מזהי ה-URI לשיתוף בזמן השיתוף. האפשרות הזו שימושית אם מזהי ה-URI לשיתוף עשויים להשתנות בהתאם להקשר של המשתמש בפעילות, ואילו קריאה ל-setBeamPushUris() שימושית כאשר מזהי ה-URI לשיתוף לא משתנים ואפשר להגדיר אותם מראש בבטחה.

גילוי שירותי רשת

ב-Android 4.1 נוספה תמיכה בגילוי שירותים מבוסס-DNS של Multicast, שמאפשר למצוא ולהתחבר לשירותים שמציעים מכשירים אחרים ברשת ה-Wi-Fi, כמו מכשירים ניידים, מדפסות, מצלמות, נגני מדיה ועוד, שרשומים ברשת המקומית.

החבילה החדשה android.net.nsd מכילה את ממשקי ה-API החדשים שמאפשרים לשדר את השירותים ברשת המקומית, לזהות מכשירים מקומיים ברשת ולהתחבר למכשירים.

כדי לרשום את השירות, קודם צריך ליצור אובייקט NsdServiceInfo ולהגדיר את המאפיינים השונים של השירות באמצעות methods כמו setServiceName(), setServiceType() ו-setPort().

לאחר מכן צריך להטמיע את NsdManager.RegistrationListener ולהעביר אותו אל registerService() באמצעות NsdServiceInfo.

כדי לחפש שירותים ברשת, צריך להטמיע את NsdManager.DiscoveryListener ולהעביר אותו אל discoverServices().

כש-NsdManager.DiscoveryListener מקבל קריאות חוזרות (callback) לגבי שירותים שנמצאו, צריך לפתור את הבעיה בשירות באמצעות קריאה ל-resolveService() ולהעביר לו אפליקציה של NsdManager.ResolveListener שמקבלת אובייקט NsdServiceInfo שמכיל מידע על השירות שאותר, כדי שתוכלו להתחיל את החיבור.

זיהוי שירותים של Wi-Fi P2P

ממשקי ה-API של Wi-Fi P2P משופרים ב-Android 4.1 כדי לתמוך בגילוי שירותים לפני השיוך ב-WifiP2pManager. כך תוכלו לזהות ולסנן מכשירים בסביבה לפי שירותים באמצעות Wi-Fi P2P לפני שתתחברו לאחד מהם, ואילו התכונה 'גילוי שירותי רשת' מאפשרת לכם לזהות שירות ברשת מחוברת קיימת (כמו רשת Wi-Fi מקומית).

כדי לשדר את האפליקציה כשירות דרך Wi-Fi, כך שמכשירים אחרים יוכלו לגלות את האפליקציה ולהתחבר אליה, צריך להפעיל את addLocalService() עם אובייקט WifiP2pServiceInfo שמתאר את שירותי האפליקציה.

כדי להתחיל חיפוש של מכשירים בקרבת מקום באמצעות Wi-Fi, צריך קודם להחליט אם תתקשרו באמצעות Bonjour או Upnp. כדי להשתמש ב-Bonjour, קודם צריך להגדיר מספר מאזינים להודעות חזרה (callbacks) באמצעות setDnsSdResponseListeners(), שמקבל גם WifiP2pManager.DnsSdServiceResponseListener וגם WifiP2pManager.DnsSdTxtRecordListener. כדי להשתמש ב-Upnp, צריך לקרוא לפונקציה setUpnpServiceResponseListener(), שמקבלת WifiP2pManager.UpnpServiceResponseListener.

כדי להתחיל לגלות שירותים במכשירים מקומיים, צריך גם לבצע קריאה ל-addServiceRequest(). כשה-WifiP2pManager.ActionListener שאתם מעבירים לשיטה הזו מקבל קריאה חוזרת מוצלחת, תוכלו להתחיל לאתר שירותים במכשירים המקומיים באמצעות קריאה ל-discoverServices().

כשהשירותים המקומיים יימצאו, תקבלו שיחה חוזרת למספר WifiP2pManager.DnsSdServiceResponseListener או WifiP2pManager.UpnpServiceResponseListener, בהתאם לשירות שאליו נרשמתם – Bonjour או Upnp. הקריאה החוזרת שמתקבלת בכל מקרה מכילה אובייקט WifiP2pDevice שמייצג את מכשיר השותף.

השימוש ברשת

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

נגישות

ממשקי API של שירותי נגישות

היקף השירותים של ממשקי ה-API לנגישות גדל משמעותית ב-Android 4.1. עכשיו אפשר ליצור שירותים שמנטרים אירועי קלט נוספים ומגיבים להם, כמו תנועות מורכבות באמצעות onGesture() ואירועי קלט אחרים, באמצעות תוספות לכיתות AccessibilityEvent,‏ AccessibilityNodeInfo ו-AccessibilityRecord.

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

ניווט באפליקציה בהתאמה אישית

כשמפתחים אפליקציות ל-Android, עכשיו אפשר להתאים אישית את סכימות הניווט על ידי חיפוש רכיבים שניתן להתמקד בהם וווידג'טים של קלט באמצעות findFocus() ו-focusSearch(), ולהגדיר את המיקוד באמצעות setAccessibilityFocused().

ווידג'טים נגישים יותר

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

העתקה והדבקה

העתקה והדבקה של כוונות

עכשיו אפשר לשייך אובייקט ClipData ל-Intent באמצעות השיטה setClipData(). האפשרות הזו שימושית במיוחד כשמשתמשים בכוונה (intent) כדי להעביר כמה מזהי URI מסוג content: לאפליקציה אחרת, למשל כשמשתפים כמה מסמכים. מזהי ה-URI מסוג content: שיסופקו בדרך הזו יהיו כפופים גם לדגלים של ה-Intent כדי להציע גישה לקריאה או לכתיבה, וכך תוכלו להעניק גישה למספר מזהי URI ב-Intent. כשמפעילים כוונה מסוג ACTION_SEND או ACTION_SEND_MULTIPLE, כתובות ה-URI שסופקו בכוונה מועברות עכשיו באופן אוטומטי ל-ClipData כדי שהנמען יוכל לקבל גישה אליהן.

תמיכה ב-HTML ובסגנונות מחרוזות

הכיתה ClipData תומכת עכשיו בטקסט עם סגנון (כ-HTML או כמחרוזות עם סגנון של Android). אפשר להוסיף טקסט בסגנון HTML ל-ClipData באמצעות newHtmlText().

רינדור

פונקציונליות החישוב של Renderscript שופרה עם התכונות הבאות:

  • תמיכה במספר ליבה (kernel) בתוך סקריפט אחד.
  • תמיכה בקריאה מהקצאה באמצעות Samplers מסוננים מ-Compute בממשק API חדש לסקריפטיםrsSample.
  • תמיכה ברמות שונות של דיוק FP ב-#pragma.
  • תמיכה בשליחת שאילתות לגבי מידע נוסף מאובייקטים של RS מסקריפט מחשוב.
  • שיפורים רבים בביצועים.

יש פרגמות חדשות גם כדי להגדיר את הדיוק של הנקודה הצפה שנדרשת על ידי המחשוב Renderscripts. כך אפשר להפעיל פעולות כמו NEON, למשל פעולות מתמטיות מהירות של וקטורים, בנתיב המעבד (CPU) שלא היו אפשריות אחרת עם תקן IEEE 754-2008 המלא.

הערה: מנוע הגרפיקה הניסיוני של Renderscript הוצא משימוש.

אנימציה

אנימציות של הפעלת פעילות

עכשיו אפשר להפעיל Activity באמצעות אנימציות של זום או אנימציות בהתאמה אישית. כדי לציין את האנימציה הרצויה, משתמשים בממשקי ה-API של ActivityOptions כדי ליצור Bundle, שאותו אפשר להעביר לכל אחת מהשיטות לתחילת פעילות, כמו startActivity().

המחלקה ActivityOptions כוללת שיטה שונה לכל סוג אנימציה שתרצו להציג בזמן פתיחת הפעילות:

makeScaleUpAnimation()
יצירת אנימציה שמרחיבה את חלון הפעילות מנקודת התחלה ספציפית במסך וגודל התחלה שצוין. לדוגמה, במסך הבית של Android 4.1 המערכת משתמשת באפשרות הזו כשפותחים אפליקציה.
makeThumbnailScaleUpAnimation()
יצירת אנימציה שמגדילה את חלון הפעילות החל ממיקום מסוים ומתמונה ממוזערת מספקת. לדוגמה, החלון 'אפליקציות אחרונות' ב-Android 4.1 משתמש בזה כשחוזרים לאפליקציה.
makeCustomAnimation()
יצירת אנימציה שמוגדרת על ידי המשאבים שלכם: אחת שמגדירה את האנימציה של פתיחת הפעילות, ואחת שמגדירה את האנימציה של הפעילות שמופסקת.

אנימציה של זמן

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

ממשק משתמש

התראות

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

סגנונות של התראות

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

Notification.BigPictureStyle
להתראות שכוללות קובץ תמונה גדול.
Notification.BigTextStyle
להתראות שכוללות הרבה טקסט, כמו אימייל יחיד.
Notification.InboxStyle
להתראות שכוללות רשימה של מחרוזות, כמו קטעי טקסט מכמה הודעות אימייל.
פעולות בעת התראה

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

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

עדיפויות

עכשיו אפשר לרמוז למערכת כמה חשוב שההתראה תשפיע על סדר ההתראות ברשימה, על ידי הגדרת העדיפות באמצעות setPriority(). אפשר להעביר את אחת מחמש רמות העדיפות השונות שמוגדרות על ידי קבועים של PRIORITY_* בכיתה Notification. ערך ברירת המחדל הוא PRIORITY_DEFAULT, ויש שתי רמות גבוהות יותר ושתי רמות נמוכות יותר.

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

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

ב-Android 4.0 (Ice Cream Sandwich) נוספו דגלים חדשים לצורך בקרה על החשיפה של רכיבי ממשק המשתמש של המערכת, למשל כדי להכהות את מראה שורת המערכת או להסתיר אותה לגמרי במכשירים ניידים. ב-Android 4.1 נוספו עוד כמה דגלים שמאפשרים לשלוט טוב יותר במראה של רכיבי ממשק המשתמש של המערכת ובפריסת הפעילות ביחס אליהם על ידי קריאה ל-setSystemUiVisibility() והעברת הדגלים הבאים:

SYSTEM_UI_FLAG_FULLSCREEN
הסתרת ממשק המשתמש של המערכת שאינו קריטי (כמו שורת הסטטוס). אם בפעילות שלך נעשה שימוש בסרגל הפעולות במצב שכבת-על (על ידי הפעלת android:windowActionBarOverlay), הדגל הזה גם מסתיר את סרגל הפעולות ועושה זאת באמצעות אנימציה מתואמת כאשר שניהם מסתירים ומציגים את השניים.
SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
מגדירים את פריסת הפעילות כך שייעשה שימוש באותו אזור מסך שזמין לאחר הפעלת SYSTEM_UI_FLAG_FULLSCREEN, גם אם הרכיבים של ממשק המשתמש של המערכת עדיין גלויים. חלקים מהפריסה יוצגו מעל ממשק המשתמש של המערכת, אבל זה שימושי אם האפליקציה שלכם מסתירה ומציגה את ממשק המשתמש של המערכת לעיתים קרובות באמצעות SYSTEM_UI_FLAG_FULLSCREEN, כי כך הפריסה לא תתאים את עצמה לגבולות הפריסה החדשים בכל פעם שממשק המשתמש של המערכת מוסתר או מופיע.
SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION
מגדירים את פריסת הפעילות כך שייעשה שימוש באותו אזור מסך שזמין לאחר הפעלת SYSTEM_UI_FLAG_HIDE_NAVIGATION (שנוספה ב-Android 4.0) גם אם הרכיבים של ממשק המשתמש של המערכת עדיין מוצגים. חלקים מהפריסה יופיעו מעל סרגל הניווט, אבל זה שימושי אם אתם מסתירים ומציגים את סרגל הניווט באפליקציה לעיתים קרובות באמצעות SYSTEM_UI_FLAG_HIDE_NAVIGATION, כי כך הפריסה לא תתאים את עצמה לגבולות הפריסה החדשים בכל פעם שסרגל הניווט מוסתר או מופיע.
SYSTEM_UI_FLAG_LAYOUT_STABLE
כדאי להוסיף את הדגל הזה אם אתם משתמשים ב-SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN ו/או ב-SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION, כדי לוודא שכאשר קוראים ל-fitSystemWindows() בתצוגה, הגבולות שהוגדרו נשארים עקביים ביחס למרחב המסך הזמין. כלומר, כשהדגל הזה מוגדר, fitSystemWindows() יפעל כאילו שקיפות רכיבי ממשק המשתמש של המערכת לא השתנתה, גם אחרי שמסתירים את כל ממשק המשתמש של המערכת.

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

צפיות מרחוק

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

משפחות גופנים

ב-Android 4.1 נוספו עוד כמה וריאציות של סגנון הגופן Roboto ב-10 גרסאות סה"כ, וניתן להשתמש בהן באפליקציות. עכשיו לאפליקציות שלכם יש גישה לקבוצה המלאה של הווריאנטים הבהירים והמוקצרים.

קבוצת הווריאנטים המלאה של הגופן Roboto זמינה:

  • רגיל
  • נטוי
  • מודגש
  • מודגש נטוי
  • חלש
  • נטוי בהיר
  • דחוסה רגילה
  • נטוי מודגש
  • מודגש דחוס
  • דחוסה מודגשת נטוי

אפשר להחיל כל אחד מהם באמצעות המאפיין החדש fontFamily בשילוב עם המאפיין textStyle.

הערכים הנתמכים של fontFamily הם:

  • "sans-serif" ל-Roboto רגילה
  • "sans-serif-light" ל-Roboto Light
  • "sans-serif-condensed" ל-Roboto דחוס

לאחר מכן תוכלו להחיל הדגשה ו/או גופן נטוי באמצעות הערכים textStyle‏"bold" ו-"italic". אפשר להחיל את שניהם כך: android:textStyle="bold|italic".

אפשר גם להשתמש ב-Typeface.create(). לדוגמה, Typeface.create("sans-serif-light", Typeface.NORMAL).

מסגרת קלט

מספר התקני קלט

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

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

כדי לקבל הודעה כשמכשירי קלט חדשים מחוברים, משתנים או מנותקים, צריך להטמיע את הממשק של InputManager.InputDeviceListener ולרשום אותו ב-registerInputDeviceListener().

רטט לפקדי קלט

אם למכשירי הקלט המחוברים יש יכולות רטט משלהם, עכשיו אפשר לשלוט ברטט של המכשירים האלה באמצעות ממשקי ה-API הקיימים של Vibrator, פשוט על ידי קריאה ל-getVibrator() ב-InputDevice.

הרשאות

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

READ_EXTERNAL_STORAGE
הרשאת קריאה מוגנת לאחסון חיצוני. ב-Android 4.1, כברירת מחדל, לכל האפליקציות עדיין יש הרשאת קריאה. השינוי הזה יתבצע בגרסה עתידית, כך שיהיה צורך באפליקציות לבקש גישה לקריאה באופן מפורש באמצעות ההרשאה הזו. אם האפליקציה כבר מבקשת גישת כתיבה, היא תקבל גם גישת קריאה באופן אוטומטי. יש אפשרות חדשה למפתחים להפעיל הגבלת גישה לקריאה, כדי שיוכלו לבדוק את האפליקציות שלהם בהתאם לאופן שבו Android תפעל בעתיד.
android.Manifest.permission.READ_USER_DICTIONARY
מאפשרת לאפליקציה לקרוא את מילון המשתמש. הרשאה כזו נדרשת רק ל-IME או לכלי לעריכת מילון, כמו אפליקציית ההגדרות.
READ_CALL_LOG
הרשאה לאפליקציה לקרוא את יומן השיחות של המערכת, שמכיל מידע על שיחות נכנסות ויוצאות.
WRITE_CALL_LOG
מאפשרת לאפליקציה לשנות את יומן השיחות של המערכת ששמור בטלפון
android.Manifest.permission.WRITE_USER_DICTIONARY
מאפשר לאפליקציה לכתוב למילון המילים של המשתמש.

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

מערכת Android 4.1 כוללת הצהרת תכונה חדשה למכשירים שמוקדשים להצגת ממשק המשתמש במסך הטלוויזיה: FEATURE_TELEVISION. כדי להצהיר שהאפליקציה שלכם דורשת ממשק טלוויזיה, עליכם להצהיר על התכונה הזו בקובץ המניפסט באמצעות הרכיב <uses-feature>:

<manifest ... >
    <uses-feature android:name="android.hardware.type.television"
                  android:required="true" />
    ...
</manifest>

התכונה הזו מגדירה 'טלוויזיה' כחוויית צפייה רגילה בטלוויזיה בסלון: הצגה במסך גדול, שבו המשתמש יושב רחוק, והקלדה נעשית בדרך כלל באמצעות מקש מעבר (D-pad), ולא באמצעות מגע או עכבר/מכשיר צביעה.