ترجمه: حالتهای مختلف ذخیره سازی اطلاعات در اندروید

1- حافظه ذخیره سازی داخلی (Internal storage)

سردرگمی های بسیاری در مورد مدلهای ذخیره سازی اندروید وجود دارد. این سردرگمی ها با تغییرات ایجاد شده در اندروید 4.4 در مورد مدلهای ذخیره سازی افزایش یافته. سوالات بیشمار موجود در StackOverflow  و شبیه آن بطور آشکار نشاندهنده عدم درک صحیح مدلهای گوناگون ذخیره سازی اندروید می باشد.

این اولین بخش از سری 5 قسمتی است که بحث مدلهای ذخیره سازی را پوشش خواهد داد، برای درک بهتر مسائل مربوط به آن. در بخش اول به مبحث حافظه های داخلی و تعاریف گوناگون آن خواهیم پرداخت.

برداشت کاربران از مفهوم حافظه داخلی ؟

هر کاربری بالاخره این صفحه از تنظیمات اندروید را مشاهده خواهد کرد از طریق آدرس Settings > Storage > Internal Storage

که باعث می شود کاربر فکر کند تمامی فضای حافظه on-board فلش دستگاه همین  حافظه داخلی نمایش داده شده است.

برداشت گوگل از مفهوم حافظه داخلی؟

افسوس، چیزی که SDK اندروید درباره معنی حافظه داخلی ارائه می دهد حاوی مطالب خلاف واقع گیج کننده ای است.

اگر شما مستندات گوگل درباره حافظه داخلی را مطالعه کنید متوجه مطالب گنگ موجود در آن خواهید شد:

«شما می توانید فایلها را مستقیما روی حافظه داخلی ذخیره کنید. بطور پیش فرض، فایلهایی که در حافظه داخلی ذخیره می شوند فقط مخصوص برنامه شما بوده و برنامه های دیگر به آنها امکان دسترسی نخواهند داشت (و حتی کاربران دیگر). وقتی که کاربر برنامه شما را حذف نصب میکند، این فایلها حذف خواهند شد.»

در حقیقت تعریف SDK اندروید درباره حافظه داخلی، صرفا یک پوشه است، که برای برنامه شما منحصر بفرد است، جایی که برنامه شما میتواند فایلهایش را ذخیره کند. همانطور که در مستندات اشاره شده، این فایلها بطور پیش فرض دارای سطح دسترسی خواندن - نوشتن برای برنامه شما و دسترسی غیر مجاز برای تمامی دیگر برنامه ها است (م: یعنی اینکه دیگر برنامه ها اجازه دسترسی به این فایلها رو ندارند).

(استثناء: کاربرانی که برنامه مدیریت فایل را با سطح دسترسی سوپر یوزر بر روی دستگاه های روت شده اجرا کنند به همه چیز امکان دسترسی خواهند داشت)

متدهای مفید چندی از Context برای دسترسی به حافظه داخلی وجود دارد از قبیل:

• getCacheDir()
• getDir()
• getDatabasePath()
• getFilesDir()
• openFileInput()
• openFileOutput()

دیگر متدها مانند()openOrCreateDatabase  و کلاس ها مانند SQLiteOpenHelper و SharedPreferences به موارد بالا وابسته بوده و تکیه دارند.

در اغلب موارد ذخیره سازی در حافظه داخلی کجا انجام می گیرد؟

اگر شما به پستهای بلاگهای متعدد، پاسخهای موجود در StackOverflow، و کتابهای منتشر شده تا سال 2012 و قبل از آن، دقت کنید، همگی به این آدرس اشاره دارند:

/data/data/your.application.package.name

(که در آن عبارت  your.application.package.name  همان نام پکیج برنامه شماست که در فایل مانیفست و یا تنظیمات Gradle تعریف شده است.)

در این آدرس پوشه هایی وجود خواهند داشت که بطور اتوماتیک توسط اندروید ایجاد می شوند وقتی که شما از بعضی از متدهای Context استفاده میکنید. مثلا ()getFilesDir یک آبجکت فایل ایجاد خواهد کرد که اشاره دارد به پوشه files داخل فضای ذخیره سازی داخلی برنامه شما.

(م: که آدرس آن به این صورت خواهد بود  /data/data/your.application.package.name/files/ ).

در بقیه موارد ذخیره سازی در حافظه داخلی کجا انجام می گیرد؟

بهرحال، آدرس فوق محل ذخیره سازی حافظه داخلی در تمامی موارد نیست. تنها قانونی که شما میتوانید از این سری مطالب ارائه شده همیشه مد نظر داشته باشید این است که:

هرگز بصورت دستی آدرسدهی نکنید.

در اکثر مواقع توسعه دهندگان بصورت زیر آدرسدهی میکنند:

 File f=new File("/data/data/their.app.package.name/files/foo.txt");

این بسیار روش غلطی است.

اول از همه در مقایسه با استفاده از دستور ()getFilesDir شما باید تایپ بیشتری انجام دهید.

 File f=new File(getFilesDir(), "foo.txt");

نکته مهم این است که همیشه آدرس محل ذخیره سازی داخلی همان آدرس استاندارد بالا نیست. در بسیاری از تبلتها از اندروید نسخه 4.2 به بعد هر کاربر دارای پروفایل اختصاصی خود است. و هر کاربر بخش ذخیره سازی داخلی مخصوص به خود دارد. در حالیکه برای کاربر اولیه همان آدرس استاندارد استفاده میشود هیچ تضمینی برای استفاده همان آدرس در مورد دیگر کاربران نیست.

کنجکاوی هایی در مورد ذخیره سازی داخلی:

بر روی یک امولاتور، با استفاده از DDMS شما میتوانید تمامی فایلهای حافظه داخلی را مرور کنید. بنابراین شما از طریق برنامه خود و یا هر برنامه دیگری میتوانید به فایل دسترسی داشته باشید.

بر روی یک دستگاه روت شده، به همان میزان آزادی عمل در کار با فایلها دارید.

بر روی یک دستگاه معمولی که روت نشده است، DDMS امکان دسترسی به فضای حافظه داخلی ندارد. بدلیل اینکه DDMS بر روی دستگاه اجرا شده بعنوان کاربر معمولی به سخت افزار دسترسی دارد، در حالیکه در محیط امولاتور با سطح دسترسی سوپر یوزر اجرا می شود. بر دستگاه روت نشده کاربر معمولی اجازه دسترسی به فایلهای برنامه شما را ندارد.

دستورالعمل دسترسی به حافظه داخلی سخت افزار استفاده از دستور adb با پارامتر run-as در خط فرمان است. بطور مثال برای دانلود یک دیتابیس از حافظه داخلی کاربر اصلی به محیط برنامه نویسی شما، باید از دستور زیر استفاده کنید:

 adb shell 'run-as your.application.package.name cp /data/data/your.application.package.name/databases/dbname.db /sdcard

 توجه داشته باشید که:

• شما باید آدرس مقصد را به جایی که حافظه خارجی در دستگاه شما تعریف شده است تغییر دهید( بطور مثال /sdcard/ که بر روی همه دستگاه ها این آدرس یکی نیست)
• بر روی دستگاه های قدیمی تر به جای cp از cap استفاده کنید.

بعد از اجرای دستور، دیتابیس بر روی حافظه خارجی کپی خواهد شد، که شما از طریق DDMS میتوانید به آن دسترسی داشته باشید، یا از هر طریق معمول دیگری مانند کابل USB (با استفاده از نام درایو در ویندوز).

محدودیت های حافظه داخلی:

در دستگاه های با نسخه اندروید 1 و 2 ، حافظه داخلی معمولا در یک پارتیشن اختصاصی قرار داشت، و این پارتیشن معمولا کوچک بود. مثل HTC Dream (a.k.a., T-Mobile G1) . یک دستگاه اندروید اصلی در کل فضای حافظه داخلی 70 مگابایتی برای تمامی برنامه ها داشت.

در دستگاه های با اندروید 2.3 به بعد فضای حافظه داخلی به مقدار 1 گیگابایت افزایش یافت.

در اندروید 3 به بعد به دلیل افزایش ظرفیت فضای ذخیره سازی داخلی مدل ذخیره سازی در کل تغییر کرد. دستگاه های با ظرفیت های حافظه داخلی 4 و 8 و 16 گیگابایتی به مارکت آمدند. در بخش بعدی به این تغییرات تحت عنوان حافظه های خارجی خواهیم پرداخت.

برای دستگاه های با اندروید 1 و 2 فضای حافظه داخلی فقط برای فایلهای کوچک بود، و شما برای بقیه اطلاعات نیازمند استفاده از حافظه خارجی بودید. در اندروید 3 برای اغلب دستگاه ها و اغلب کاربران، حافظه داخلی مناسب بود برای فایلهایی که بطور روتین استفاده نمیشد توسط دیگر برنامه ها و یا فایلهایی که بطور مستقل از برنامه شما توسط کاربر مورد دسترسی قرار نمیگرفت. تعدادی از کاربران حرفه ای، به این نتیجه رسیده بودند که حتی حافظه فلش آنبورد دستگاه به اندازه کافی فضا برای ذخیره اطلاعات مورد نظر آنها را ندارد، بنابراین آنها به سمت حافظه های خارجی متمایل شدند.

پرسش های متداول:

آیا من میتوانم در فضای حافظه داخلی فایلهایی با قابلیت خواندن و نوشتن جهانی ایجاد کنم؟

خیر. از FileProvider استفاده کنید و برای ارائه مطلب مورد نظر از پیاده سازی توسط ContentProvider استفاده کنید. سپس، شما حداقل امکان استفاده از سیستم کنترل سطح دسترسی اندروید برای مدیریت دسترسی به این فایلها را خواهید داشت، در عوض اینکه هر برنامه ای بتوانند این فایلها را دستکاری کنند.

بسیار خوب، نظرتان درمورد android:sharedUserID چیست؟

توصیه ای در این مورد هست:

android:sharedUserId خصوصیتی است که میتوان در مانیفیست  برای ایجاد یک شناسه کاربری منطقی برای برنامه تان، ست کرد. هر برنامه دیگری که با همان کلید علامت گذاری نصب شده باشد و همان android:sharedUserId  را درخواست کند از سطح دسترسی کاربری یکسان در لینوکس استفاده خواهد کرد. و این باعث خواهد شد که این دو برنامه امکان دسترسی به فایلهای یکدیگر را داشته باشند.

این خصوصیت در واقع برای برنامه های از پیش نصب شده (pre-installed) طراحی شده است، مانند تعدادی از برنامه هایی که از قبل بارگذاری شده هستند توسط کارخانه سازنده، یا carrier و یا پشتیبانی کننده حالت ROM. بخصوص،  یک بار که شما برنامه تان را ارسال میکنید، شما بطو مطمئنی نمی توانید مقدار android:sharedUserId را تغییر دهید بدون اینکه کاربر خود را ازحالت قفل روی فایلهای موجود خارج کنید. بخاطر اینکه اندروید مالکیت فایلهای موجود را تغییر نمیدهد وقتی که کاربر لینوکسی که برنامه شما را اجرا میکند تغییر میکند.

در حالتیکه چندین پروسس بطور همزمان با یک فایل کار میکنند ریسکهای زیادی وجود دارد. تعدادی از زیرسیستمها مانند Sqlite، دارای یک الگوریتم طراحی شده درونی، برای برخورد با این حالت هستند. اما اگر شما خود دسترسی به فایلهای خود را مدیریت میکنید، (از طریق دستوراتی مانند File و یا java I/O) باید به طریقی خود حالت دسترسی همزمان را مدیریت کنید که ممکن است حتی نیاز به شعبده بازی باشد.

همچنین شما باید حالتی را که یک برنامه حذف نصب می شود و فایلهایی را که برنامه دیگر با آنها کار میکند میخواهد پاک کند مدیریت کنید. در مدل hub-and-spoke ، مثل یک برنامه و تعدادی پلاگین، شاید آنقدر ریسکی نباشد. در مدلهای دیگر، که برنامه ها بسیار شبیه هم هستند، شما نمی توانید اجازه دهید که اطلاعات برنامه شما ناپدید شود بخاطر اینکه کاربر برنامه دیگری را حذف نصب کرده است.

در پایان شما نمی دانید که در آینده چه چیزی پیش خواهد آمد، در حال حاضر، شما باید به برنامه های خود به دیده یک مجموعه به هم منسجم شده نگاه کنید. کسی که این برنامه ها را بدست می آورد، ممکن است مایل به تغییر مسیر باشد، با استفاده از امکان به اشتراک گذاری اطلاعات، که آزادی عمل بیشتری دارند، مانند ContentProvider ، به شما انعطاف پذیری بیشتری نسبت به حالتی که فرض کنید برنامه های شما همکاری مشترکی در استفاده از فایلها خواهند داشت، میدهد. در یک دنیای ایده آل، برنامه شما با برنامه های دیگر بطور نسبتا قابل اعتمادی عمل خواهد کرد اما نه مثل منابع همیشه در دسترس، دقیقا مثل عملکرد وب سرویس شما.

چگونه من روی دستگاه های روت شده جلوی دسترسی کاربر به اطلاعات برنامه ام در حافظه داخلی را بگیرم؟

خیلی ساده است. فایلهای خود را در حافظه داخلی قرار ندهید. کاربران دستگاه های روت شده به هرجا که دلشان بخواهد دسترسی دارند، بنابراین تنها راه جلوگیری از دسترسی آنها به فایلهای شما این است که فایلهایتان را روی حافظه داخلی دستگاه قرار ندهید.

بعضی از توسعه دهندگان سعی میکنند که فایلهای خود را کدگذاری کنند. مثلا با استفاده از یک رمز خیلی پیچیده، که این کار باعث ایجاد کاهش سرعت خواهد شد. اما این کمترین عیبش خواهد بود. ممکن است توسط یک نفر که علاقمند به استفاده از مهندسی معکوس برنامه شما می باشد روش کدگذاری فایلهای شما را کشف کرده و در یک پس بلاگ و یا انجمن نحوه عملکرد برنامه شما را افشا کند.

در کل تعداد نسبتا کمی هستند که دستگاه های روت شده دارند. حدس زده می شود که تعداد آنها حدود 1% باشد(م: از نظر نویسنده). بهترین راه این است که شما  بر روی کار مهندسی خود برای تولید برنامه بهتر تمرکز کنید تا اینکه وقت خود را جهت جلوگیری از دسترسی کاربران دستگاه های روت شده صرف کنید.

پایان بخش اول

2- حافظه ذخیره سازی خارجی (External storage)

از دید کاربران «حافظه ذخیره سازی خارجی» چه معنی دارد؟

بسیاری از کاربران اندروید هیچ ایده ای در مورد معنی حافظه خارجی ندارند، در رابط کاربری دستگاه هیچ کجا از این عبارت استفاده نشده است.

کاربرانی که بخش Settings > Storage را می بینند فقط قسمت «Internal Storage» را می بینند:

و یا آنها هر دو اینها یعنی «Internal Storage» و «SD Card» را می بینند:

از این رو، در بهترین حالت، کاربران فکر میکنند که SD card همان حافظه خارجی است. این اصلا درست نیست. تنها فقط برای اندروید 4.4 صحیح می باشد. (بله این واقعا گیج کننده است)

نظر گوگل در مورد External storage چیست؟

در مستندات گوگل این چنین آمده است:

«هر دستگاه سازگار با اندروید، از یک حافظه ذخیره سازی خارجی اشتراکی پشتیبانی میکند که شما میتوانید فایلهای خود را در آن ذخیره کنید. آن می تواند مثلا یک حافظه ذخیره سازی جداشدنی مثل SD card باشد و یا حافظه ذخیره سازی داخلی جدانشدنی باشد. فایلهای ذخیره شده در حافظه خارجی قابلیت خواندن همگانی دارند و امکان ویرایش توسط کاربر وقتی که امکان حالت انتقال USB از طریق کامپیوتر فعال است، را دارند.»

اکثریت قریب به اتفاق مطالبی که در این مورد نوشته شده، چه در مستندات و چه در جاهای دیگر، درباره اندروید نسخه قبل از 4.4 بوده است. در آن روزهای خوب و آرام سال قبل، فقط یک درایو تک به عنوان حافظه خارجی وجود داشت. و آن بطور موثری این چنین تعریف شده بود: «درایوی که وقتی کاربر دستگاه خود را با کابل USB به کامپیوتر وصل کرده ظاهر می شود.» علی رغم اینکه این تعریف دقیق نبود بسیاری از تولید کنندگان تجهیزات به دستگاه های خود این امکان را میدادند که با استفاده از کابل USB درایو مربوط به دستگاه شان در کامپیوتر در دسترس کاربران قرار گیرد. و اندروید 4.4 اضافه کرده است تغییرات بیشتری در تعریف مدیاهای جداشدنی.

بطور مشخص حافظه خارجی با استفاده از دستور () Environment.getExternalStorageDirectory  قابل دسترسی می باشد.

مکانهای زیادی که حافظه خارجی در آنها ذخیره می شود:

حافظه های خارجی، همانند تاج خروس است که با وزش هر بادی به این سو و آن سو می رود.

در اندروید 1 و 2 حافظه خارجی عموما بصورت مدیای جداشدنی بود معمولا از نوع یک کارت میکرو SD . با تاکید بسیار، در دستگاه های اندروید 1 و 2 حافظه های خارجی بصورت یک پارتیشن جداگانه و با فایل سیستم جدا وجود داشتند. هنگامی که تعداد کمی از دستگاه های اندروید 2.3 اتنخاب شدند تا در آنها برای حافظه های خارجی از فلشهای آنبورد استفاده شود، هنوز هم آنها بصورت یک پارتیشن جداگانه از پارتیشن مربوط به حافظه داخلی استفاده میشدند. در نتیجه، ما با دستگاه هایی روبرو بودیم که تبلیغ ظرفیت ذخیره سازی چند گیگابایتی را داشته باشند ولی بیشتر این فضا برای حافظه خارجی استفاده میشد که کاربر معمولی امکان تغییر اندازه آن را نداشت.

در اندروید 3 همه چیز تغییر کرد. هر دو فضاهای داخلی و خارجی بر روی یک پارتیشن پیاده سازی شد، بصورت ساختار درختی پوشه های جداگانه. این کار به کاربران قابلیت انعطاف پذیری بالایی میداد، بطوریکه در حال حاضر هیچ تمایز خاصی نمیتوان بین حافظه داخلی و حافظه خارجی قائل شد. تولید کنندگان دستگاه ها، میتوانستند انتخاب کنند که حافظه خارجی رو بصورت یک پارتیشن جداگانه در نظر بگیرند و یا حتی بصورت مدیای جداشدنی درنظر بگیرند، اما آنها اکثرا این کار را انجام ندادند.

مسیرهای گوناگونی که در حافظه خارجی ذخیره می شوند:

برای ما بعنوان توسعه دهندگان، مسیر واقعی دسترسی به این حافظه خارجی جادوئی طی سالیان مختلف تغییر کرده است. از sdcard به storage و سرانجام در حال حاضر به /mnt/shell/emulated/0 تغییر کرده است.  و بعنوان کاربر ثانویه در تبلتهای اندروید 4.2 آنها فضای حافظه داخلی اختصاصی و حافظه خارجی اختصاصی با دایرکتوری ریشه اختصاصی خود، دارا هستند.

همانطور که در بخش قبل تاکید شد:

هرگز بصورت دستی آدرسدهی نکنید.

از متدهای متنوع برای بدست آورد دایرکتوری اصلی استفاده کنید... که به نظر در طول سالیان بسیار پیچیده شده است.

در ابتدا همگی از دستور () Environment.getExternalStorageDirectory  استفاده میکنند. که به ریشه دایرکتوری حافظه خارجی اشاره دارد. این حافظه خارجی را شبیه یک بسکت بزرگ از مطالب تصادفی میکند.

بعدها گوگل سازماندهی بیشتر را ارائه داد:

• getExternalFilesDir() and getExternalCacheDir() on Context  اشاره دارد به پوشه اختصاصی برنامه در حافظه خارجی. همانی که موقع حذف نصب برنامه آنها نیز پاک خواهند شد.
• ()Environment.getExternalStoragePublicDirectory مکانهای متمرکز شده برای انواع فایلهای شناخته شده مانند: عکسها و فیلمها و موزیکها

توجه داشته باشید که متدهای Context حالتهای مجموعه نیز دارند (getExternalFilesDirs() and getExternalCacheDirs())  که مخصوص حافظه های جداشدنی هستند که در بخش بعد بررسی میشود.

حافظه های خارجی و اجازه های دسترسی:

صرفا اگر مکان حافظه های خارجی - چه فیزیکی و چه منطقی - تغییر کند آیا ما قادر به کار کردن با آنها خواهیم بود.

در اصل برنامه های هر کاری را که بخواهند انجام میدهند.

اندروید 1.5 سطح دسترسی WRITE_EXTERNAL_STORAGE را ایجاد کرد. که به برنامه ها این اجازه را می داد که در حافظه خارجی فایلها را بنویسند. به همین دلیل، موقع نصب برنامه به کاربر اطلاع داده میشد که برنامه امکان نوشتن بر روی حافظه خارجی را دارد. همچنین هر برنامه میتوانست از حافظه خارجی بخواند.

در حال حاضر اندروید 4.4 سطح دسترسی READ_EXTERNAL_STORAGE فراهم کرده است.بنابراین شما حتی اجازه خواندن از حافظه خارجی را هم نخواهید داشت اگر سطح دسترسی مربوطه را فعال نکرده باشید. توجه داشته باشید که  WRITE_EXTERNAL_STORAGE   دلالت بر READ_EXTERNAL_STORAGE  دارد. بنابراین شما به یکی از آنها نیازمندید نه هردو. و برای () getExternalFilesDir() and getExternalCacheDir  شما به هر دوی این سطح دسترسی ها نیاز ندارید. شما میتوانید در این دایرکتوریها هم بنویسید و هم بخوانید(در صورتی که سطح دسترسی نوشتن فعال باشد). اندروید در حال حاضر خصوصیت android:maxSdkVersion را در <uses-permission> دارا می باشد. به طور ویژه، شما میتوانید از WRITE_EXTERNAL_STORAGE در صورتیکه به آن نیاز ندارید، استفاده نکنید، چرا که شما فقط با getExternalFilesDir() and getExternalCacheDir() کار میکنید.

کنجکاوی بیشتر درباره حافظه خارجی:

به عنوان یک توسعه دهنده، با فرض اینکه متناسب با نسخه اندروید استفاده شده آدرس حافظه خارجی را میدانید، شما از طریق DDMS چه در امولاتور و چه در دستگاه تجاریتان، دسترسی نامحدود به آن خواهید داشت .

شما همچنین میتوانید همانند کاربران دیگر از یک کابل USB استفاده کنید. بهرحال،  در نظر داشته باشید که حافظه خارجی عینا همانند رابط کاربری USB نمی باشد ولی در عوض، هرآنچه که در حافظه خارجی شما اندکس شود در MediaStore ظاهر خواهد شد. از این رو، تا وقتی که شما مراحل لازم را طی کنید برای کسب اطمینان از اینکه فایلهای ایجاد شده شما ایندکس خواهند شد، آنها بلافاصله ظاهر نخواهند شد.

 اندروید از پروتکل انتقال مدیا (Media Transfer Protocol - MTP) برای ارتباطات USB استفاده میکند. این قابلیت انعطاف پذیری بیشتری نسبت به حالت Mass Storage Mode دارد. بهرحال:

• بعضی از کلاینتهای MTP ممکن است listings های دایرکتوری را کش کنند . بنابراین حتی بعد از اینکه فایل شما توسط MediaStore ایندکس شد، نیاز به ریفرش کردن کلاینت است.

سوالهای متداول:

چگونه میتوان فایلهای خود را در حافظه های خارجی ایمن کرد؟

در حالت کلی شما نمیتوانید. کاربر دسترسی کامل به حافظه خارجی دارد. و برنامه ها هم در صورت ست شدن سطح دسترسی مورد نیاز به تمامی فایلها دسترسی دارند.

یکی از کارهایی که شما میتوانید انجام دهید استفاده از چیزی شبیه Conceal فیسبوک است. با کمک این ابزار شما فایلهای خود را در حافظه خارجی میتوانید کد کنید، اما کلید کدگذاری تولید شده در حافظه داخلی نگهداری میشود. از نقطه نظر امنیتی، اثر اصلی آن این است که حافظه خارجی را شبیه حافظه داخلی از لحاظ دسترسی خواندن میکند. توجه داشته باشید که این ابزار از پاک شدن فایلهای شما در حافظه خارجی توسط کاربر و یا برنامه های دیگر، و یا شاید نوشتن روی فایلهای شما و در نتیجه خراب کردن آنها نمیکند.

حالت برنامه روی SD چطور است؟

همانطور که در بخش قبل اشاره شد حافظه داخلی ظرفیت کمی به اندازه 70 مگابایت دارد. (م: گیج کننده است)

قیل و قال زیادی درباره نصب برنامه بر روی حافظه خارجی وجود دارد، بعنوان راه حلی که برای برنامه های فضای بیشتری ایجاد میکند. در اندروید 2.2 قابلیتی با نام android:installLocation attribute on the root <manifest> element در فایل مانیفست ایجاد شد.

بهرحال وقتی که اندروید 3 از راه رسید، این واقعا بلااستفاده ماند، بدلیل آنکه حافظه داخلی و خارجی از یک پارتیشن مشترک استفاده میکردند.

به نظر نویسنده وقتی انتقال برنامه های به حافظه خارجی مفید خواهد بود که دستگاهی داشته باشید که حافظه خارجی بصورت یک پارتیشن جداگانه وجود داشته باشد.

در حال حاضر قیل و قال مربوطه به سمت انتقال برنامه ها بر روی حافظه های جداشدنی منتقل شده است. بطوریکه کاربران حرفه ای تا به اندازه 32 گیگابایت فضا برای برنامه های خالی کرده اند. این ممکن است که گوگل خاصیت android:installLocation را برای پشتیبانی از حافظه های جداشدنی توسعه دهد.

 پایان بخش دوم.

3- حافظه ذخیره سازی قابل جابجایی (Removable storage)

از دید کاربران «حافظه ذخیره سازی قابل جابجايي» چه معنی دارد؟

بسياري از كاربران دستگاه هايي دارند كه نوعي از حافظه جداشدني دارد. در اغلب موارد اين يك ميكرو SD است. بعضي از تبلتها يك SD كارت كامل دارند. و علاوه بر آن امكان استفاده از حافظه هاي USB با استفاده از كابل OTG دارند.

بسياري از كاربران تصور ميكنند كه با حافظه هاي جداشدني همانند كاربرد آنها در كامپيوترها مي توانند استفاده كنند.

متاسفانه بسياري از اين كاربران در اشتباه هستند، و با وجود اندرويد 4.4 نيز مرتكب اشتباهات بيشتري مي شوند. اين بخاطر روش عجيب و غريب گوگل در استفاده از حافظه هاي جداشدني است.

نظر گوگل درمورد حافظه هاي جداشدني چيست؟

در اوايل كار حافظه هاي جداشدني بصورت حافظه ميكرو SD بودند. در آن زمان بسياري از توسعه دهندگان فكر ميكردند كه حافظه هاي خارجي برابر است با حافظه هاي جداشدني.

بهرحال با شروع اندرويد 3 و نسخه هاي بالاتر آن توسعه دهندگان متوجه دو نكته زير شدند:

1- در بسياري از دستگاه ها حافظه خارجي برابر با حافظه جدا شدني نيست.
2- در SDK اندرويد هيچ چيزي در مورد حافظه هاي جداشدني نيامده است.

يه لحظه!، يعني چي؟

اين مطلب كاملا درست است: تا قبل از اندرويد 4.4 ، هيچ پشتيباني رسمي در مورد حافظه هاي جداشدني وجود نداشت. نقل قولي از Dianne Hackborn:

... بخاطر داشته باشيد: تا قبل از اندرويد 4.4 ، نسخه رسمي سيستم عامل اندرويد هيچ گونه پشتيباني از SD card ها  به دو صورت رايج موجود نداشت: ذخيره سازي بصورت قديمي كه به شكل استفاده از SD card‌ بود (كه امروز هنوز توسط سيستم عامل پشتيباني مي شود) و قابليتهاي محدودي كه به اندرويد 3 اضافه شده بود تا بتواند SD كارتهاي افزوده شده را اسكن كرده و آنها را به media provider اضافه كند تا برنامه ها امكان دسترسي فقط خواندن روي فايلهايشان داشته باشند (كه اين نيز هم اكنون در سيستم عامل پشتيباني مي شود).

اندرويد 4.4 اولين نسخه منتشر شده اي است كه واقعا به برنامه ها براي ذخيره سازي امكان استفاده از SD كارتها را مي دهد. هر گونه دسترسي به اين نوع حافظه ها تا قبل از آن، بصورت اختصاصي، و با API هاي پشتيباني نشده بود. ما هم اكنون داراي يك API قدرتمند در سيستم عامل براي استفاده برنامه ها از اين نوع حافظه ها با پشتيباني بسيار بهتر نسبت به روشهاي قبلي، هستيم. آنها ميتوانند از فضاي ذخيره سازي برنامه بصورت آزادانه بدون نياز به اجازه دسترسي خاصي در برنامه استفاده كنند و به همه فايلهاي موجود روي SD كارت بدون نياز به اجازه دسترسي خاصي ، دسترسي داشته باشند.

اما ... اما... يه لحظه... پس اين همه برنامه اي كه از حافظه هاي جداشدني استفاده ميكردند چه ميشوند؟

آنها در سه گروه دسته بندي مي شوند:

1- تعدادي از آنها كه متكي به ايندكس MediaStore هستند. بطور مثال، يك برنامه پخش ويدئو كه امكان يافتن تمامي فيلمهاي موجود در تمامي مدياهاي ذخيره سازي در دسترس را با استفاده از درخواست جستجوي كل MediaStore را دارد. اگر سازنده دستگاه امكان جستجوي MediaStore بر روي تمامي حافظه هاي در دسترس را غيرفعال نكرده باشد برنامه پخش فيلم توانايي پخش همه فيلمهاي موجود روي تمامي حافظه در دسترس را خواهد داشت.

2- تعدادي از برنامه ها كه به همراه سخت افزار مربوطه مي باشد. توليد كننده سخت افزار مربوطه به تمامي ريزه كاريهاي سخت افزار توليد خود مسلط بوده و از نحوه عملكرد آن آگاه است. همچنين توليد كننده سخت افزار نگراني درباره اجراي اين برنامه برروي دستگاه هاي ديگر و يا ارائه آن در Play Store ندارد. بنابراين توليد كننده سخت افزار براحتي به برنامه اجازه كار با  حافظه جداشدني را مي دهد.

3- تعدادي از برنامه ها نيز هستند كه توسط توسعه دهندگان براي گذر از محدوديت هاي SDK اندرويد نوشته مي شوند. دستورالعملهاي آنلاين گوناگوني براي تست انواع فايل سيستم لينوكس جهت تعيين نقاط mount شده در دسترس وجود دارد و چه قابليتهايي را براي حافظه هاي جداشدني ارائه ميدهد. در حاليكه قابليت اعتماد در دستگاه هاي مختلف ميتواند خود مشكلي باشد، اين تكنيك ها جواب ميدادند. تا زمان انتشار اندرويد 4.4 كه همه چيز تغيير كرد.

تغييرات در اندرويد 4.4: اخبار خوب

در اندرويد 4.4 دو اتفاق درباره حافظه هاي جداشدني افتاد.

ما بطور رسمي در SDK اندرويد شاهد پشتيباني از حافظه هاي جداشدني بوديم. مخصوصا، getExternalFilesDirs() and getExternalCacheDirs()(به حالت جمع بودن متدها دقت كنيد). اين متدها نه تنها دايركتوريهايي را كه ما بر روي حافظه خارجي «واقعي» ميتوانيم استفاده كنيم برميگردانند بلكه دايركتوريهايي را كه بر روي تمامي حافظه هاي جداشدني قابل دسترس و پشتيباني وجود دارند برميگردانند. برنامه هاي ما نيازي به هيچ اجازه دسترسي خاصي براي كار با اين آدرسها ندارند.

همچنين، فريمورك دسترسي به حافظه هاي ذخيره سازي به توليد كنندگان دستگاه هاي اندرويدي اين امكان را ميدهد كه اجازه كنترل بيشتر و بهتري بر روي حافظه هاي جداشدني از طريق برنامه ها داده شود.

به نقل قول از Jeff Sharkey:

«برنامه ها امكان ايجاد كردن يا نوشتن خارج از دايركتوري اختصاصي پكيج اصلي برنامه بر روي دستگاه هاي ذخيره سازي خارجي ثانويه با استفاده از اينتنت CREATE_DOCUMENT داشته باشند كه كاربر را در پروسه ايجاد فايل دخيل ميكند.»

تغييرات در اندرويد 4.4: اخبار نگران كننده

پس از اندرويد 4.2، گوگل از توليد كنندگان دستگاه ها درخواست كرده بود كه حافظه هاي جداشدني را قفل كنند، كه عموما مورد توجه قرار نگرفت.

در اندرويد 4.4، گوگل پروسه تست سازگارپذيري (Compatibility Test Suite (CTS) ) خود را اصلاح كرد كه توليد كنندگان دستگاه ها بايد مطابق آن دستگاهي را كه قرار است برنامه هاي اختصاصي گوگل را بر روي خود اجرا كنند، توليد كنند. نقل قول از Dave Smith:

«بهرحال تستهاي جديدي كه به CTS‌ در اندرويد 4.4 اضافه شده ، چك ميكند كه آيا حافظه ثانويه، اجازه دسترسي فقط خواندني مناسب براي برنامه ها بر روي دايركتوري غير از پكيج اصلي برنامه دارد يانه؟ احتمالا بخاطر  API هاي جديدي كه اين آدرسها را در اختيار توسعه دهندگان قرار ميدهند. به محض افزوده شدن اين قوانين به CTS ، سازندگان سخت افزارها مجبور به توليد دستگاه هايي شدند كه برنامه هاي اختصاصي گوگل  (GMS ) را بطور پيش فرض و آنبورد داشته باشند.»

در نتيجه، برنامه ها ميتوانند فايلهاي موجود در حافظه جداشدني را، با استفاده از روشهاي غيرمستند و پشتيباني نشده براي يافتن حافظه هاي جداشدني، بخوانند. بهرحال، برنامه ها نميتوانند محتويات حافظه جداشدني را بنويسند و يا ويرايش كنند. توجه داشته باشيد كه توليد كنندگان دستگاه ها خود ممكن است در اين مورد مشكلي نداشته باشند ولي بطور معمول اين امكان براي توسعه دهندگان برنامه ها وجود ندارد.

گروه گوگلي android-platform صفحه   a rather epic discussion thread  را در مورد تصميم گوگل در اين مورد با توجه به صحبتهاي Dave Smith  دارند. 

با وجود تمامي اين مباحث، نويسنده توقع برگشت به عقب گوگل درباره اين مشكل را ندارد. براي هر كاربري كه در مورد بي استفاده كردن ميكرو SD ها توسط گوگل ناراضي است ؛ نارضايتي هايي نيز درباره دسترسي آزاد و بي در و پيكر به فضاي ذخيره سازي برنامه ها وجود دارد، كه باعث بروز مشكلات امنيتي و نقض حريم خصوصي مي شود. در واقع، نويسنده متعجب نخواهد شد اگر در آينده دسترسي به فضاي خارج از فضاي اختصاصي برنامه بر روي حافظه هاي جداشدني مسدود شود.

از كجا ميتوان اطلاعات بيشتري كسب كرد؟

اين دو لينك قبلا هم در اين نوشته اشاره شده بودند:

Dianne Hackborn: توضيحاتي درمورد تصميمات فعلي و آينده گوگل
Dave Smith: توضيحاتي در مورد نحوه اجراي اين تصميمات

پايان بخش سوم.

4- اشتباهات گوگل در این موضوع (Where Google went wrong with all of this)

جائيكه گوگل گمراه ميشود:

در اين بخش به برخورد گوگل با موضوع حافظه هاي جداشدني و عواقب اين تصميمات پرداخته ميشود.

«اگر پيشنهاد شما خلاف معمول است، شما بايد با عواقب آن روبرو شويد»

حالت معمول در اينجا توقعاتي است كه درباره حافظه قابل جابجايي وجود دارد.

در سال 1973 در كنار بقيه رويدادها سه رويداد زير به وقوع پيوست:

1- متولد شدن Larry Page
2- متولد شدن Sergey Brin
3- ارائه فلاپي ديسك درايو با قابليت نوشتن و خواندن توسط شركت  IBM

در دهه 1970 فلاپي ديسكها بعنوان تنها وسيله ذخيره سازي اصلي اطلاعات در ميكروكامپيوترها مورد استفاده قرار گرفتند و ارتباط جهانيان با دستگاه هاي ذخيره سازي قابل جابجايي شروع شد.

آقاي Page ‌و آقاي Brin در سال 1998 اقدام به تاسيس گوگل كردند. بنابراين مردم خيلي قبل تر از اينكه گوگل به دنيا بيايد و كاربران گوگل بوجود بيايند، از حافظه هاي قابل جابجايي استفاده ميكردند.

برداشت عمومي از نحوه استفاده از حافظه هاي قابل جابجايي مبتني بر مجموعه تجربه هاي آنها در كار با سيستم عاملهاي دسكتاپ بود مخصوصا ويندوز. سيستم عامل ويندوز دليل آن است كه چرا استاندارد حافظه هاي قابل جابجايي در ابتدا FAT16 و سپس FAT32 بود كه فاقد امكانات امنيتي بود. برنامه هايي كه در ويندوز اجرا ميشدند بطور عمومي اجازه دسترسي نوشتن و خواندن بدون محدوديت داشتند. و همين روال نيز در ديگر سيستم عاملها حين كار كردن با حافظه هاي قابل جابجايي FAT16/FAT32 ، بكار مي رفت.

ميليونها كاربر دستگاه هاي اندرويدي براساس تجربه خود در استفاده كردن از حافظه هاي قابل جابجايي در سيستم عاملهاي دسكتاپ ، با همان طرز تفكر نيز در دنياي اندرويد از اين حافظه ها استفاده ميكردند.

اندرويد 4.4 اين طرز تفكرات را از بين برد، و باعث نگراني برنامه هاي third-party‌ شد. اين پيشنهاد (برنامه هاي third-party اجازه دسترسي نوشتن روي حافظه قابل جابجايي را نداشته باشند) متفاوت با حالت نرمال (اجازه انجام هركاري توسط هر چيزي) بود.

اين بدين معني نيست كه تصميم گوگل در اين مورد اشتباه بوده است.

طبق گواهي NSA امنيت ابزارهاي قابل جابجايي در طول تاريخ بسيار مخاطره آميز بوده است. اين به اين معني نيست كه ما مجبور باشيم براي هميشه طبق دستورالعمل نحوه استفاده از ابزارهاي قابل جابجايي در سالهاي 1970 و يا 1980 پيروي كنيم. گوگل تا حدودي در مورد قفل كردن استفاده از حافظه هاي خارجي و قابل جابجايي به لحاظ مسائل حريم خصوصي، تحت فشار بوده است، حتي اگر مخالف توقعات نرمال جامعه در استفاده از حافظه هاي قابل جابجايي باشد.

گوگل مجبور است از ايده «تقسيم بچه بين طرفين» پيروي كند. با بكارگيري امكان انتخاب در تنظيمات بين دو حالت دسترسي آزاد و دسترسي محدود فقط خواندني اندرويد 4.4 به حافظه هاي قابل جابجايي. گوگل امكان ارائه قابليتهايي (امكان فعال يا غيرفعال كردن اجازه دسترسيها)  براي كاربران حرفه اي را مسكوت گذاشته است.

نكته اي كه باقي مي ماند اين است كه «گوگل بيش از اين خود را درگير اين موضوع نكرده است». تنها راه ارتباطي براي كسب اطلاعات در اين مورد گروه گوگلي android-platform مي باشد.

اگر ابزارهاي جابجاشدني زمان تاسيس گوگل كشف شده بودند و هيچ انتظارات پيش فرضي در نحوه استفاده از آنها وجود نداشت، و اندرويد 4.4 اولين نسخه منتشر شده اندرويد بود، اين كمبود اطلاعات تاسف آميز ولي بي دليل نبود. بهرحال ابزارهاي جابجاشدني داراي سابقه اي بيش از 40 سال هستند ولي اندرويد رفتارهاي متفاوتي از 2008 با ابزارهاي جابجاشدني داشته است.

«اگر شما پيشنهادي غيرنرمال داريد، بايد با تبعات آن نيز روبرو شويد»

با اين حال، تنها به اين دليل كه گوگل با مسائل در اين زمينه خود را روبرو نميكند باعث نميشود كه شما با مسائل در اين زمينه روبرو نگرديد.

پايان بخش چهارم.

5- اشتباهات توسعه دهندگان (برنامه نویسان) در این موضوع (Where developers went wrong with all of this)

اگر برنامه شما از كدهاي مخاطره آميز استفاده ميكند بايد اين موارد به كاربر اطلاع رساني شود.

منظور از مخاطره آميز بودن آن است كه بر روي دستگاه هاي مختلف و يا نسخه هاي مختلف اندرويد داراي مشكل باشد. زيرا اين كدها از تكنيكهايي استفاده ميكنند كه:

•  غير مستند هستند،
• فاقد پشتيباني رسمي هستند و
• حداقل هاي مورد نياز سازگاري اندرويد را پوشش نميدهند.

 با رجوع مجدد به گفته هاي  Dianne Hackborn:

«... بخاطر داشته باشيد: تا قبل از اندرويد 4.4 ، نسخه رسمي سيستم عامل اندرويد هيچ گونه پشتيباني از SD card ها  به دو صورت رايج موجود نداشت: ذخيره سازي بصورت قديمي كه به شكل استفاده از SD card‌ بود (كه امروز هنوز توسط سيستم عامل پشتيباني مي شود) و قابليتهاي محدودي كه به اندرويد 3 اضافه شده بود تا بتواند SD كارتهاي افزوده شده را اسكن كرده و آنها را به media provider اضافه كند تا برنامه ها امكان دسترسي فقط خواندن روي فايلهايشان داشته باشند (كه اين نيز هم اكنون در سيستم عامل پشتيباني مي شود).

اندرويد 4.4 اولين نسخه منتشر شده اي است كه واقعا به برنامه ها براي ذخيره سازي امكان استفاده از SD كارتها را مي دهد. هر گونه دسترسي به اين نوع حافظه ها تا قبل از آن، بصورت اختصاصي، و با API هاي پشتيباني نشده بود. ما هم اكنون داراي يك API قدرتمند در سيستم عامل براي استفاده برنامه ها از اين نوع حافظه ها با پشتيباني بسيار بهتر نسبت به روشهاي قبلي، هستيم. آنها ميتوانند از فضاي ذخيره سازي برنامه بصورت آزادانه بدون نياز به اجازه دسترسي خاصي در برنامه استفاده كنند و به همه فايلهاي موجود روي SD كارت بدون نياز به اجازه دسترسي خاصي ، دسترسي داشته باشند.»

البته اين خبر جديدي نيست.

تا زمانيكه در مستندات توضيح بهتري در اين مورد گنجانده شود (an programming anti-patterns section, to line up with the design anti-patterns)) به ما گفته شده كه به مدت زمان طولاني ابزارهاي جابجاشدني پشتيباني نميشوند. اين نكته در بسياري از پاسخهاي StackOverflow به آن اشاره شده است من جمله اين مورد، كه از آن استقبال فراواني هم شده و تغييرات در اندرويد 4.4 هم در آن لحاظ شده است.

اگر شما از موارد زير استفاده ميكنيد به ياد داشته باشيد كه از تكنيكهاي غير مستند و فاقد پشتيباني و نا مطمئن بر روي دستگاه هاي مختلف و نسخه هاي مختلف اندرويد استفاده ميكنيد:

•  تست فايل سيستمهاي لينوكس (مانند: /proc/mounts)
• اجراي فرمانهاي سيستم عامل لينوكس (مانند: mount )
• استفاده از رفلكشن براي بدست آوردن متدها يا كلاسهايي كه برچسب hide@ دارند و به همين دليل آنها بخشي از SDK اندرويد نمي باشند.
• آدرسدهي دستي به منابع اختصاصي گوگل و يا برنامه هاي AOSP مانند نام پكيج و يا مقادير ContentResolver Uri

 مسلما اين بدين معني نيست كه شما نميتوانيد از اين روشها استفاده كنيد. بلكه اگر هم استفاده كرديد بايد به كاربر هشدار دهيد كه قابليتهاي برنامه بين دستگاه هاي مختلف و يا نسخه هاي مختلف اندرويد متفاوت خواهد بود.

شباهتهاي بسياري در علامتگذاري محصولات مصرفي و در قوانين موجود است. بطور مثال نظري به ملزومات افشاي ريسك در كميسيون تبادلات و امنيت ايالات متحده (SEC) بيندازيم:

محصولاتي كه بطور عمومي به بازار تجاري عرضه مي شوند بايد اطلاعات دقيقي در مورد زمان عرضه عمومي، بروزرساني هاي دوره اي، بهمراه SEC ، ارائه دهند. يكي از اطلاعات ساليانه فرم 10K مي باشد. طبق توضيحات ويكي پيديا:

با وجود نامگذاري مشابه ، گزارش ساليانه فرم 10K از گزارش ساليانه سهامداران كه يك شركت به سهامداران خود در جلسه انتخاب هيئت مديره ارائه ميدهد،  متمايز است. (هر چند بعضي از شركتها گزارش ساليانه و گزارش فرم 10K را بصورت مشتركا يك سند ارائه ميدهند). فرم 10K شامل اطلاعاتي نظير تاريخچه شركت، ساختار سازماني، پاداشهاي هيئت اجرايي، تساوي حقوق منصفانه، شركتهاي تابعه، صورتهاي مالي حسابرسي شده، و اطلاعات ديگر، مي باشد.

مخصوصا بخش 1A از فرم 10K به بحث ريسك فاكتور اختصاص دارد، كه نقاط مخاطره آميز را براي سرمايه‌گذاران فاش ميسازد. در بعضي موارد، آن مخاطره ها بطور محض داخلي هستند، مانند اعتماد به نوآوريهاي بخش پروسه هاي مهندسي. در بعضي موارد، مشكلات بيروني هستند،‌ مانند انتظار براي دادخواهي هاي قضايي، يا تغيير در قوانين (وضع قوانين جديد توسط قانونگذاران). عموما ريسكها مواردي هستند كه مربوط به خود شركت ميشوند، و يا مربوط به بخش تجاري و بازار شركت، بيشتر از آنكه ريسكها مربوط به ناحيه بومي باشند (مانند حوادث غيرمترقبه).

بطور مثال فرم 10K گوگل براي پايان سال 2013، داراي 10 صفحه در مورد ريسكهاي تجاري است از «رقابتهاي شديد» گرفته تا «بلوك شدن تبليغات گوگل توسط تكنولوژيهاي جديد».

دليل اين اطلاع رساني ها، آگاهي دادن به سرمايه گذاران درباره درجه ريسك پذيري شركت مي باشد. بطور تاكتيكي، اين ميتواند براي شركت بد باشد، چونكه باعث افت قيمت سهام ميگردد. به لحاظ استراتيژيكي،‌ اين اطلاع رساني ها باعث كمك در پرونده هاي حقوقي و نظارتهاي آتي مي گردد، با نشان دادن اينكه شركت يك «شهروند خوب» بوده و در مورد مسائل مجهول شفافيت معقولي دارد.

از نقطه نظر خط مشي عمومي، چنين اطلاع رساني هايي باعث آگاهي سرمايه گذاران ميگردد، (با مطالعه فرم 10K) و يا عدم آگاهي آنان (درصورت نخواندن فرم 10K) . اين يعني اينكه SEC سرمايه گذاران را مجبور به كسب اطلاعات درباره شركت نميكند، بلكه باعث ميشود در صورت تمايل سرمايه گذاران به كسب اطلاعات آنها به خوبي از همه چيز آگاه باشند.

اگر شما مايل به درگير شدن در پرونده هاي حقوقي نيستيد، ويا مايل به اعمال فشار از طرف نهادهاي نظارتي براي برچسبگذاري برنامه توسط علامتگذاريهاي خوب مصرفي ديگر نيستيد ( يا بدتر از آن، بطور حقوقي و مجازاتهاي كيفري بدليل عدم آشكارسازي ريسك فاكتورهاي شناخته شده) شما نيازمند به تهيه مستندات لازم در اين مورد هستيد. اين فكر كه توسعه دهندگان برنامه بعنوان بخشي از  ديگر صنايع واقعي، زندگي ميكنند حماقت محض است.

اين نميتواند كار سختي باشد.

اولا، مستندات برنامه را بنويسيد. بله اين كار خسته كننده اي است. بسياري از كاربران اصلا آنرا نميخوانند ولي بهرحال شما آنرا انجام دهيد.

دوما، اگر قابليتي از برنامه را توضيح ميدهيد كه از يك تكنيك داراي ريسك استفاده كرده است،‌ خيلي ساده فقط آنرا مشخص كنيد. (توجه داشته باشيد كه اين يعني اينكه اين قابليت بر روي تمامي دستگاه ها و يا تمامي نسخه هاي اندرويد قابل اجرا نيست.)

سوما، مطمئن شويد كه مستندات بطور منطقي قابل دسترس مي باشد،‌ تا كاربران بهانه اينكه به مستندات دسترسي نداشته اند را نداشته باشند. اگر شما مستندات برنامه را بر روي وب سايت خود قرار داده ايد، گزينه HELP را بصورت شناور روي صفحه در تمام اكتيويتي ها قرار دهيد كه به آدرس آن روي وب سايت اشاره دارد.

البته ممكن است بعضي از توسعه دهندگان اين رفتار صادقانه با كاربران را نپسندند چرا كه ممكن است باعث كاهش فروش برنامه گردد (بصورت پرداخت درون برنامه اي و يا استفاده از تبليغات). اين ممكن است در دوره كوتاهي از اجراي برنامه باعث كاهش فروش شود.

توسعه دهندگان ديگر ممكن است از نارضايتي كاربران به خاطر از دست دادن آن قابليتها شكايت كنند. حتي اگر به ريسك آن اشاره شده باشد. اين حقيقت دارد كه تمامي كاربران يك ذره از مستندات برنامه را نخواهند خواند. اجازه دهيد يادآوري كنم كه استفاده از تكنيكهاي با ريسك بالا فقط باعث ايجاد ريسك ميگردد. شما بر روي اين موضوع تكيه ميكنيد كه استفاده از اين تكنيكها بر روي تعداد دستگاه كافي و يا اكثر نسخه هاي سيستم عامل جوابگو مي باشد، بنابراين شما خود به خوبي از اين موضوع آگاه هستيد كه ممكن است برنامه شما بر روي بعضي سيستمها و در بعضي حالتها جوابگو نباشد. اين دليل مخالفت استفاده از اين تكنيكها مي باشد.

اما از نگاه ديگر، اين بدين معني است كه شما با نگفتن اين موضوع به كاربران از گوگل بهتر نيستيد. گوگل در مورد اينكه قصد عدم امكان استفاده از ابزارهاي جابجاشدني را دارد، اطلاع رساني درستي نكرده است، و شما هم در اين مورد تحت تاثير قرار ميگيريد. شما هم بدرستي به كاربران خود در مورد امكان استفاده برنامه شما از ابزارهاي جابجاشدني براساس مفروضات اطلاع رساني نكرده ايد، و كاربران شما در اين مورد تحت تاثير قرار ميگيرند. اين رفتار گوگل شرم آور است. تا زمانيكه مسوليت جوابگويي را به عهده خود شما نميگذارد، اين رياكارانه است. حتي اگر حوزه عمل متفاوت باشد (عدم اطلاع رساني گوگل مردم خيلي بيشتري را نسبت به شما تحت تاثير قرار ميدهد مگر برنامه شما بطور ديوانه واري مشهور شود).

كارهاي ديگري هم هست كه شما در اين مورد ميتوانيد انجام دهيد:

•  اگر شما واقعا نميدانيد كه تكنيك استفاده شده بطور رسمي مستند شده و يا پشتيباني ميشود يا نه در StackOverflow سوال كنيد و يا از سايتهاي ديگر پشتيباني توسعه دهندگان اندرويد استفاده كنيد.
• اگر شما حس ميكنيد كه بعضي از قابليتها داراي ريسك مي باشد، اما ارزش قبول اين ريسك را دارد، سعي كنيد تا يك لايبرري اوپن سورس بسازيد تا همان قابليت را  به روش API ارائه دهد. هدف اين است كه به بسياري از توسعه دهندگان قابليت به اشتراك گذاري يك روش پياده سازي تك را بدهد؛ بنابراين با كمك اين ترفند بر تفاوت بين دستگاه ها غلبه ميكنيم. همچنين، اين روش  امكان  تامين راه حلهايي براي حالتي كه قابليت ظاهرا بلوك شده، ارائه ميدهد. كه در اينجا امكان نوشتن بر روي ابزارهاي جابجاشدني است. و گروهي از توسعه دهندگان سازمان يافته يك لايبرري را نوشته و پياده سازي ميكنند براي قابليت پشتيباني نشده اي كه تدريجا با احتمال زياد قادر به يافتن تغييرات آينده اندرويد در زمينه آن قابليت،  ميشود. بنابراين شما ميتوانيد برروي اينكه چه برنامه ريزي داشته باشيد تصميم بگيريد.

در نهايت اين سوال باقي مي ماند كه آيا تغييرات در اندرويد 4.4 در مورد ابزارهاي جابجاشدني آيا بطور بهتري مديريت خواهند شد؟ بهرحال اين اولين باري نيست كه گوگل تصميم ميگيرد كه رفتار اندرويد را از طريق شكستن تكنيكهاي مستند نشده و پشتيباني نشده، تغيير دهد. و مسلما اين آخرين بار هم نخواهد بود. تنها ميتوان اميد داشت كه:

•  گوگل در مورد اين تغييرات بهتر اطلاع رساني كند (تغييرات SMS در 4.4 به خوبي بصورت اطلاع رساني هاي پيشرفته و توضيحات مورد انتظار مديريت شد.)
• توسعه دهندگان توجه بيشتري به پيامدهاي استفاده از روشهاي غير مستند و پشتيباني نشده داشته باشند، و به كاربران خود در مورد مشكلات بالقوه قبل از بروز واقعي آنها اطلاع رساني كنند.

پايان قسمت پنجم.