1- تفاوت HashMap و HashTable:
کلاس HashMap از نوع synchronize نیست پس thread-safe نیست. اما کلاس HashTable از نوع synchronize هستش.
کلاس HashMap بخاطر synchronize نبودن کمی سریعتر از HashTable عمل میکنه.
کلاس HashMap اجازه داشتن یک کلید null و چندین مقدار null رو داره، اما کلاس HashTable همچین اجازه ای رو نداره.
کلاس HashMap زیرکلاس AbstractMap هستش، اما کلاس HashTable زیرکلاس Dictionary هستش.
کلاس HashTable تقریباً منسوخ شده و باید از جایگزینش ConcurrentHashMap استفاده بشه.
و...
در بیشتر موارد کلاس HashMap استفاده میشه، درصورتی که synchronization در اولویت نباشه.
2- برای حل مشکل ValueError: unsupported pickle protocol در لینوکس کافیه فایل .repopickle_.gitconfig در Android SDK رو پیدا و حذف کنید.
3- اصول طراحی کلاس:
- همیشه داده ها و فیلدها رو private نگهدارید و از اصول encapsulation پیروی کنید.
- همیشه فیلدها رو initialize کنید.
- هرکلاس رو به یک نوع/دسته از داده اختصاص بدید.
- کلاسهای چند منظوره با چند مسئولیت طراحی نکنید، بلکه آنها را تجزیه و جداسازی کنید.
- بی دلیل برای همه فیلدها و داده ها accessor و mutator طراحی نکنید. (set/get)
- همیشه بهترین و مناسبترین نام رو برای کلاس و متد تعیین کنید تا هدف رو بخوبی انعکاس بدهند.
- حتاالمکان کلاسها رو immutable (غیرقابل تغییر) طراحی کنید.
- بجای استفاده مکرر تودرتو if/else switch foreach از interface یا کلاس abstract استفاده کنید.
- حتاالمکان کلاس رو static طراحی نکنید. (بخاطر global state و مشکلات unit testing)
- از نوشتن متدهای طولانی و سنگین خودداری کنید. معمولاً متدهای طویل نشاندهنده رفتار و وظایف متعدد هستش که نیاز به تجزیه و refactoring داره.
- از قانون DRY (مخفف Don’t Repeat Yourself) پیروی کنید... متدهای تکراری رو با ساخت superclass abstract یکی کنید.
1- بهتره همیشه شماتیک :file رو در کلاس WebView رو مسدود کنید.
کلاس WebView قابلیت نمایش صفحات وب در داخل اکتیویتی رو فراهم میکنه، و از اونجایی که دیگر برنامه ها قادرن Intent URI به WebView ایجاد شده بفرستن، پس این امکان رو هم دارن تا بتونن فایل یا آدرس URI آلوده رو در دستگاه بارگذاری کنن...
راه حل:
String _intentUrl = getIntent().getStringExtra("http://blog.ir");
if (!_intentUrl.startsWith("file:"))
{
loadUrl = _intentUrl;
}
2- از انجایی که همه برنامه ها قادرن محتوای logcat رو read کنن، هرگز اطلاعات حساس رو برای دیباگ Log نکنید، مخصوصاً درخواستها و پاسخهای HTTP رو.
3- اگر در حین بازکردن برنامه Eclipse با خطای Java was started but returned exit code 13 مواجه شدید، این یعنی مثلاً Java 64bit نصب کردید، درصورتی که Eclipse تون 32bit هستش. یا Java 32bit نصب کردید، درصورتی که Eclipse تون 64bit هستش.
بنابراین باید معماری هردو یکی باشه... مثلاًً هردو 32bit یا هردو 64bit باشن.
نکته: در صورت حل نشدن مشکل با نصب معماری مناسب، فایل eclipse.ini رو که در کنار فایل اجرایی Eclipse تون هست رو باز کنید و بدنبال واژه –vm بگردید... بعد در زیر این واژه مسیر نصب شده Java رو جایگزینش کنید...
و یا برنامه Eclipse رو باز کنید و به مسیر Menu -> Prefecences -> Java -> Installed JREs برید و مسیرنصب شده Java رو بهش بدید...
نکته اینکه دستور در نرم افزار Android Studio 3 و Gradle 3 و جدیدتر منسوخ شده و بجاش باید از دستور compileimplemention استفاده بشه. (میتونید براحتی و بدون مشکل جایگزینشون کنید)
پس باید بگیم فرق دستور api با دستور implemention چیه:
api به اصطلاح حکم public کردن یک کتابخانه رو دارههمونطور که با public کردن یک متد میتونید اون متد رو برای همه کلاس ها و پکیج ها share و قابل دسترسی کنید، توسط دستور api هم میتونید محتویات یک کتابخانه رو برای کل پروژه share و قابل استفاده کنید. (درواقع توسط دستور api، کتابخانه مورد نظر در همه جای پروژه "رخنه" میکنه)
implemention به اصطلاح حکم private کردن یک کتابخانه رو دارههمونطور که با private کردن یک متد میتونید اون متد رو از همه کلاس ها و پکیج ها "مخفی و غیر قابل دسترسی" کنید که " فقط در محل خودش قابل استفاده باشه"، توسط دستور implemention هم میتونید محتویات یک کتابخانه رو فقط برای برنامه یا کتابخانه ای که ازش استفاده کرده "نمایان و قابل استفاده" کنید. implementation کتابخانه رو برای ماژولهای دیگر پروژه پنهان میکنه و به کدهای داخلی محدود میکنه.
مثلا:
MyApp -> Lib -> Lib2
👆 در اینجا برنامه MyApp به کتابخانه Lib وابستست، و کتابخانه Lib به کتابخانه Lib2 وابستست...
با api کردن Lib2 باعث میشید تا محتویات این کتابخانه در کل پروژه قابل دسترس باشه.
اما آیا واقاً لازم دارید؟
dependencies
{
api project(':Lib2')
}
مثلا اگر متد sendRequest() در کتابخانه Lib2 قرار گرفته باشه و فقط کتابخانه Lib از این متد استفاده کرده باشه، با api کردن Lib2 اون متد هم در اختیار شما و کل پروژه خواهد بود. چیزی که واقاً لازم نیست...
زمانی باید از دستور api استفاده کنید که میخوایید از محتویات یک کتابخانه که برای یک کتابخانه دیگر هست استفاده کنید. 👆 مثل Lib2
یا پروژه تون کلاً یک کتابخانست. مثل SugarORM یا Log4J یا Volley یا ApacheHTTP...
✅ همیشه باید از دستور implemention استفاده کنید. اینطوری خود Gradle plugin تشخص میده که آیا لازمه به api تغییر کنه یا نه.
درصورت بروز خطا، بدونید که به اشتباه از متدهای کتابخانه های تودرتو و زیرین استفاده کردید پس باید رفعش کنید.
Android Gradle plugin engineer Jerome Dochez: When you switch to the new Android Gradle plugin 3, you should replace all yourcompile(andapi) with theimplementationkeyword.implementation / testImplementation / androidTestImplementation

کتابخانه OkHTTP
توسط Square تولید شده. مناسب برای Streaming و استفاده General مبتنی بر HTTP. پشتیبانی از POST, GET, UPLOAD. دارای مستندات آموزشی. زیربنای پیشفرض Retrofit و Picasso. یکی از زیربناهای Volley هستش. دارای disk cache. پشتیبانی از conn pooling. از پروتکل SPDY پشتیبانی می کنه. از اندروید 4.4 به بعد بصورت builtin در زیربنای اندروید استفاده شده. پشتیبانی از NewIO و...
کتابخانه Retrofit
توسط Square تولید شده. مناسب برای RESTful API / Web Service. پشتیبانی از POST, GET, PUT, DELETE, Multipart. دارای مستندات آموزشی. مبتنی بر کلاینت OkHTTP. دارای disk cache. پشتیبانی از async با کمترین کد. دارای cancellation و retryy برای درخواست ها. پشتیبانی از Dynamic URL. کمی کندتر از Volley اما سریعتر از AsyncTask هستش. دارای مفسر پیشفرض JSON و تبدیلش به POJO بکمک GSON. پشتیبانی از NewIO. پشتیبانی از فعالیت های background.
کتابخانه Volley
توسط Google پشتیبانی شده. مناسب برای استفاده General و کار با تصاویر. پشتیبانی از POST, GET, PUT, DELETE. دارای مستندات آموزشی. دارای کلاینت های OkHTTP, Apache, HttpUrlConnection. دارای memory cache. پشتیبانی از conn pooling. پشتیبانی از async با کمترین کد. دارای prioritization, cancellation, retrying برای درخواست ها. پشتیبانی از Dynamic URL. کمی سریعتر از Retrofit هستش. پشتیبانی از Image loading. دارای bitmap caching. سازگاری مناسب با activity lifecycle. دارای memory error handing مناسب. هندل کننده duplicate calls. استفاده نسبتاً آسان.
البته اگر بدنبال کتابخانه های سبکتر و کوچیکتر HTTP می گردید این گزینه ها هم میتونن انتخاب خوبی باشن:
LoopJ's android-async-http (HttpClient)
http://loopj.com/android-async-http/
Fast-Android-Networking
https://github.com/amitshekhariitbhu/Fast-Android-Networking
jus
https://github.com/apptik/jus
RoboSpice
https://github.com/stephanenicolas/robospice
این نکته رو هم در نظر داشته باشید که هرکدوم مزایا و معایب خودشونو دارن و باید درجای مناسبش کتابخانه مناسب رو انتخاب کنید.

این دیاگرام رو درست کردم تا روند(internals) کامپایل، تولید و اجرای برنامه های جاوا رو نشون بده:
برای بزرگنمایی کلیک کنید
Java internals, Java structure, JVM internals, ساختار جاوا، ساختمان جاوا
یکی از کاملترین و دقیق ترین دیاگرامهای Java/JVM internals موجود در اینترنت هستش
اطلاعات بیشتر:
http://blog.jamesdbloom.com/JVMInternals.html
1- فراموش نکنید که مقدار صفت android:updatePeriodMillis در تگ <appwidget-provider فایل xml/widget_info.xml بیانگر تایمری هست که کالبک onUpdate کلاس ویدجت صدا زده میشه.
2- در metadata ویدجت، مقدار صفت android:minHeight و android:minWidth تعیین کننده حداقل اندازه ویدجت هستش که باید 72dp (یعنی 1x1) باشه. ولی صفت android:layout_width و android:layout_height در layout ویدجت، تعیین کننده اندازه کنونی ویدجت هستش.
3- از انجایی که List متدی برای اضافه کردن عنصر نداره و سایزش هم ثابت هست، برای تبدیل Array به ArrayList باید به این روش عمل کنید:
ArrayList<String> _arrayList = new ArrayList<String>(Arrays.asList(myArray));
4- برای چک کردن وجود یک مقدار در آرایه کافیست به این صورت عمل کنید:
Arrays.asList(myArray).contains(targetValue);
5- نکته جزیی: فراموش نکنید که HashMap در جاوا در واقع همون data structure هستش و نه آرایه!
1- برای رفع خطای OutOfMemory هنگام کار با تصاویر راه های زیر رو دنبال کنید:
- مقدار خاصیت largeHeap در فایل مانیفست رو true قرار بدید.
- سعی کنید از LRU cache manager استفاده کنید.
- تصاویر رو compress کنید.
- کدهارو بررسی کنید که memory leak رخ نداده باشه. (که 90% بخاطر بی توجهی به activity life cycle رخ میده)
- برای سرویس ها و Toast ها از ApplicationContext استفاده کنید.
- دقت کنید که broadcast receiver ها رو Unreg کنید.
- همه Observer ها رو بعد از استفاده delete کنید.
- همه resource ها رو(مثل XML) بعد از استفاده destroy کنید.
مقاله کامل و قابل فهم از حافظه Stack و حافظه Heap.
2- مقدار صفت android:targetSdkVersion در تگ uses-sdk فایل AndroidManifest.xml، به دستگاه با نسخه مشابه SDK فرمان میده که سیستم compability رو غیرفعال کنه. بنابراین سرعت پردازش برنامه افزایش و کارایی برنامه بهبود پیدا می کنه.
3- یادتون باشه که synchronized و Thread-Safe در جاوا یک مفهوم دارن: دسترسی همزمان به کد توسط چند Thread بدون بروز مشکلات. یعنی کد/متد synchronized اجازه دسترسی همزمان چند Thread به کد/متد رو نمیده، پس Thread ها باید نوبتی به کد/متد دسترسی پیدا کنن بنابراین آخرین وضعیت کد/متد در همه Thread ها مشترک هستش.
نکته: این مسئله فقط در مورد برنامه های Multi-Thread صدق میکنه و نه Single-Thread.
4- برای حل مشکل minSdk(API x) != deviceSdk(API y) در Android Studio یکی از راه های زیر رو دنبال کنید:
راه اول: داخل گوشی/emulator به مسیر Settings -> منوی Developer options برید و گزینه USB debugging رو فعال کنید.
راه دوم: زمانی که گوشی/emulator رو وصل می کنید، داخل گوشی پنجره Allow USB Debugging باز میشه که حاوی fingerprint هم هست... اون رو ALLOW کنید.
راه سوم: مطمعن شید که حافظه گوشی/emulator پر نشده باشه... اگر شده خالیش کنید.
راه چهارم: داخل گوشی/emulator به مسیر Settings -> منوی Storage برید و از بالا options رو باز کنید، سپس گزینه USB computer connection رو بزنید و نهایتا Media device MTP رو فعال کنید. (اگر درست نشد، Camera device رو فعال کنید)
راه پنجم: نسخه targetSdkVersion و compileSdkVersion رو یکی کنید.
راه ششم: فایل build.gradle رو باز کنید و مقدار عددی minSdkVersion رو به مقدار عددی deviceSdk تغییر بدید.
راه هفتم: داخل Android Studio به منوی Tools -> گزینه Android برید و ADB Integration رو فعال کنید.
راه هشتم: داخل Android Studio به قسمت Build Tools Version برید و نسخه رو به مقدار عددی minSdk یا deviceSdk تغییر بدید.
راه نهم: کلاً از device های سری Preview, N, L استفاده نکنید.
1- با اضافه کردن خاصیت android:supportsRtl="true" در تگ application فایل AndroidManifiest.xml، مشکل راست به چپ صفحات preferences تون حل خواهد شد. (برای اندروید 4.2 به بعد)
2- آیا میدونید هیچ تفاوتی بین fill_parent و match_parent در خاصیت عناصر گرافیکی وجود نداره و هر دو دارای مقدار 1- هستند؟
این مسئله فقط یک تغییر نام جزیی بوده که از API 8 به بعد صورت گرفته و پیشنهاد شده که از match_parent استفاده بشه.
3- از انجایی که SharedPreference ها عملیات read/write برروی دیسک انجام میدن و معمولاً هم در متد OnCreate() یا OnResume() فراخوانی و load می شن، پس بهتره در thread غیر از UI اعمال بشن، تا برنامه رو دچار وقفه نکنن.
همچنین لازم نیست نگران تعدد عملیات باشید، چراکه SharedPreference یک شی Singleton هست و فقط یکبار بارگذاری میشه.
4- در بیشتر مواقع با استفاده از عبارات زیر در تعاریف HttpURLConnection کدتون، خطای recvfrom failed: ECONNRESET (Connection reset by peer) برطرف خواهد شد:
System.setProperty("http.keepAlive", "false");
myHttpUrlConnection.setRequestProperty("connection", "close");
5- برای حل مشکل GC overhead limit exceeded در برنامه Eclipse کافیه ظرفیت حافظه Heap این برنامه رو در فایل eclipse.ini تغییر بدید:
-XX:MaxPermSize=1024m -Xms512m -Xmx1024m