سری برنامه های Learn x شرکت Solo Learn برای یاد گیری زبان های برنامه نویسی بسیار مفید هستند.

این برنامه با دارا بودن بخش های جذاب و متنوع، شما را حیرت زده خواهد کرد. استفاده از گیمیفیکیشن و تعریف مرحله، آزمون های چند گزینه ای و حتی Editor برای نوشتن و تست کد از بخش های جذاب این برنامه هست و به راحتی می توانید جاوا را شروع کنید.

مرحله های برنامه عبارتند از:

Basic Concepts

Conditionals and Loops

Arrays

Classes and objects

Classes and objects Level2

Exceptions, Lists, Threads

از نرم افزار های آموزشی دیگر این شرکت می توان به آموزش های  C++, python, Swift, C#, php, Ruby, SQL می باشد. مشخصات برنامه ها را می توانید در اینجا ملاحظه نمایید.

نوشته Learn Java اولین بار در Mahdi Tajik پدیدار شد.

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

آیا راهی علمی و نسبتاً دقیق برای پیاده سازی طرح طراح بدون سعی و خطا وجود دارد؟؟

شاید بصورت چشمی و دستی تغییراتی را اعمال می کنید و به نتیجه مطلوب می رسید و یا شاید هم مثل من برای آن راه کاری پیدا کرده اید.

مشکل کجاست؟

مشکل از آنجایی پیش آمده که تولید کننده گان زیادی برای گوشی های اندروید وجود دارند و هرکدام گوشی های متنوعی با سایز گوناگون و کیفیت تصویر گوناگون تولید می کنند. این مشکل در آیفون وجود ندارد و تنوع گوشی های آن بسیار پایین است. البته ما می توانیم این تهدید را به راحتی به فرصت تبدیل کنیم. در این مقاله تلاش می کنم تا استانداردهای گوگل را باهم برسی کرده و راهکار مناسبی ارائه دهیم. پس تا آخر این مطلب با من باشید!

اصطلاحات و مفاهیم

Screen density

تراکم صفحه به معنای تعداد نقاط موجود در صفحه برای نمایش بر اینچ می باشد.(از آنجایی که اکثر واحد های اندروید به اینچ است، ما هم با همین واحد کار خواهیم کرد. ) صفحه با تراکم low یعنی صفحه ای که در فضای فیزیکی آن تعداد پیکسل های کمی در مقایسه با صفحات normal و high وجود دارد. جزو مشخصات هرگوشی یک مشخه به عنوان تراکم تصویر با واحد dpi موجود است. به عنوان مثال گوشی samsung galaxy s6 دارای تراکم پیکسلی ۵۵۷ dpi است. ( واحد dpi و ppi هردو برای تراکم هستند و در صفحه موبایل هردو به یک معنا هستند. ) این واحد ربطی به سایز صفحه ندارد و ممکن است گوشی بزرگی باشد که تعداد پیکسل های آن کم باشد و گوشی کوچکی داشته باشیم که تراکم پیکسلی بسیار بالایی داشته باشد. بالعکس آن هم صادق است.

Resolution

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

Density-independent pixel (dp)

واحد مجازی و جایگزین پیکسل است  از آن جهت مشخص کردن اندازه ها و فاصله ها استفاده کنیم. هدف از تعریف dp ایجاد واحدی مستقل از تراکم صفحه است تا بتوان با استفاده از آن واحد در تمامی صفحات اندازه یکسانی داشته باشیم. حال ببینیم dp از کجا امده است؟

همانطور که در بالا اشاره شد تراکم های پیکسلی گوناگونی برای گوشی های اندروید وجود دارد و گوگل برای ساده کردن این تعداد زیاد، آنها را به دسته هایی تقسیم بندی کرده و یکی را یعنی ۱۶۰ dpi را به عنوان شاخص گوشی ها در نظر گرفته است. این دسته بندی به شکل زیر است:

بازه کامل تر با نمایی دیگر را ملاحظه فرمایید. همانطور که می بینید برای راحتی کار از هر بازه یک عدد را به عنوان نماینده آن بر می گزینیم و با آن نام صدا می زنیم. مثلا تمام گوش هایی که تراکم تصویری آنها بین ۱۰۰dpi و ۱۴۰dpi باشد از نظر ما ۱۲۰dpi بوده و در بازه ldpi یا low-dpi قرار می گیرد.

بازه ها بطور دقیق تر عبارتند از: ( میانگین معیار بازه تا معیار بازه بعدی )

ldpi    ۱۰۰ – ۱۳۹
mdpi    ۱۴۰ – ۱۹۹
hdpi    ۲۰۰ – ۲۷۹
xhdpi   ۲۸۰ – ۳۶۹
xxhdpi   ۳۷۰ – ۵۵۹
xxxhdpi      ۵۶۰ – x

حال بر می گردیم به تعریف dp. بسیار ساده است! یک dp برابر است با دقیقاً یک پیکسل وقتی که dpi ما ۱۶۰ باشد.  وقتی در اندازه هایمان از dp استفاده کنیم خود اندروید آن را طوری محاسبه می کند که این اندازه تقریباً در تمامی گوشی ها یکسان به نظر برسد و طبق همین گفته با تقریب خوبی همیشه یک اینچ برابر ۱۶۰dp در هر گوشی می شود.  فرمول محاسبه pixel از روی dp بدین صورت است:

px = dp * (dpi / 160)

dp / dpi = inch پس یعنی ۱۶۰dp در در گوشی

حال این به چه معنی است؟ این فرمول می گوید مثلا اگر مارجین را در طراحی ۱۶dp بدهیم در گوشی با mdpi همان ۱۶px می شود. در گوشی hdpi برای نمایش این ۱۶dp از (۱۶*(۲۴۰/۱۶۰)) = ۲۴px استفاده می کند تا طرح ما یکسان به نظر برسد. زیرا ضریب تراکم ما ۱ شد که ضربدر تعداد پیکسل به ۲۴ رسیدیم. با قرار دادن dpi ها در فرمول به ضرایب زیر می رسیم:

• ldpi = 0.00625 * 120 -> 0.75
• mdpi = 0.00625 * 160 -> 1.0
• hdpi = 0.00625 * 240 -> 1.5
• xhdpi = 0.00625 * 320 -> 2.0
• xxhdpi = 0.00625 * 480 -> 3.0
• xxxhdpi = 0.00625 * 640 -> 4.0

راهکار چیست؟

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

Explicitly declare in the manifest which screen sizes your application supports

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

<supports-screens android:xlargeScreens="true" />

<supports-screens android:compatibleWidthLimitDp="320" />

که می گوید کوچکترین عرض ممکن ۳۲۰dp خواهد بود و در گوشی هایی که این شرایط را ندارند قابل ارائه نخواهد بود. مثلا با کد زیر برنامه ما فقط برای تبلت ها قابل دسترس خواهد کرد.

<compatible-screens android:smallScreens="false"
                  android:normalScreens="false"
                  android:largeScreens="true"
                  android:xlargeScreens="true"
                  android:requiresSmallestWidthDp="600" />

Provide different layouts for different screen sizes

بصورت پیش فرض اندروید layout ها و چیدمان ها را بر اساس سایز صفحه تغییر سایز می دهد. این تغییر اکثرا مشکلی ندارد اما در برخی موارد ممکن است خوب به نظر نرسد و لازم باشد که اندازه ها و چیده مان ها تغییر کنند. برای همین امر فولدر هایی داریم که می توان بر اساس آنها لیوت های گوناگون داشته باشیم تا در شرایط مختلف بر اساس سایز تصویر، مورد استفاده قرار گیرند. برای این کار کافی است که layout های مختلف را با نام یکسان در فولدرهای مختلف قرار دهیم. به عنوان مثال می توانید main.xml را با طراحی دیگر برای تبلت داخل فولدر  layout-sw600 قرار دهید و با این کار به اندروید می گوییم که اگر حداقل عرض صفحه ۶۰۰dp بود از layout های داخل این فولدر استفاده کن.

Provide different bitmap drawables for different screen densities

بطور پیش فرض اندروید تصاویر شما را جهت نمایش در سایز های گوناگون تغییر سایز می دهد. ولی همانطور که می دانیم این امر سبب می شود تا کیفیت نمایشمان خیلی خوب نباشد. بهتر این است که ورژن های متفاوتی از تصاویر و بیتمپ هایمان را در سایز های گوناگون قرار دهیم تا اندروید با توجه به dpi صفحه مناسب ترین را جهت استفاده انتخاب و با کمترین تغییر سایز مورد استفاده قرار دهد. همانطور که پیش تر گفتیم چون dpi ها دارای رنج هستند یعنی مثلاً از ۱۴۱dpi تا ۲۰۰dpi جزو ۱۶۰dpi قرار می گیرند و منابع یکسانی استفاده می شود، لذا ممکن است در گوشی ۲۰۰dpi یک تصویر کمی کشیده شده و سپس مورد استفاده قرار گیرد.

روش استفاده از منابع توسط اندروید بدین صورت است:

۱- اول سیستم باتوجه به dpi گوشی وارد فولدر منابع می شود و اگر بتواند منابع را از داخل آن بر می دارد. به این پوشه ها توصیف کننده های اندازه می گویند. ( size qualifiers ) اگر نتوانست وارد پوشه منابع با اولویت بعدی می شود. سپس درصورت نیاز با اعمال تغییر سایز اندک مورد استفاده قرار می دهد. پوشه های منابع drawable بصورت زیر نامگذاری می شوند:

drawable/
drawable-en/
drawable-fr-rCA/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/

که بخش های آن عبارتند از:

Locale = en-GB
Screen orientation = port
Screen pixel density = hdpi
Touchscreen type = notouch
Primary text input method = 12key

۲- درصورتی که منبع مورد نظر در dpi ما یافت نشد، اندروید تصویر پیش فرض را بر می دارد و با تغییر سایز از آن استفاده می کند. منظور از پیش فرض همان منابعی هستند که در پوشه drawable/ قرار گرفته اند.

فولدر هایی که برای منابع می توانیم استفاده کنیم به شرح ذیل است. کافی است که یک تصویر را در سایز های مورد نیاز با نام یکسان در پوشه های مورد نیاز قرار دهیم.

مثال:

res/layout/my_layout.xml              // layout for normal screen size ("default")
res/layout-large/my_layout.xml        // layout for large screen size
res/layout-xlarge/my_layout.xml       // layout for extra-large screen size
res/layout-xlarge-land/my_layout.xml  // layout for extra-large in landscape orientation

res/drawable-mdpi/graphic.png         // bitmap for medium-density
res/drawable-hdpi/graphic.png         // bitmap for high-density
res/drawable-xhdpi/graphic.png        // bitmap for extra-high-density
res/drawable-xxhdpi/graphic.png       // bitmap for extra-extra-high-density

res/mipmap-mdpi/my_icon.png         // launcher icon for medium-density
res/mipmap-hdpi/my_icon.png         // launcher icon for high-density
res/mipmap-xhdpi/my_icon.png        // launcher icon for extra-high-density
res/mipmap-xxhdpi/my_icon.png       // launcher icon for extra-extra-high-density
res/mipmap-xxxhdpi/my_icon.png      // launcher icon for extra-extra-extra-high-density

توصیف کننده های جدیدی وجود دارند که بر اساس dp هستند. مثلا sw600dp می گوید دیوایس هایی که حد اقل عرض آنها ۶۰۰dp باشد. ( فرمول تبدیل dp  از روی dpi و تعداد px را در اوایل مقاله گفته ایم.)

dp = px / (dpi / 160)

و کد آن:

private void showDensity() {
    
    Display display = getWindowManager().getDefaultDisplay();
    Point size = new Point();
    display.getSize(size);
    float width = size.x;
    float height = size.y;
    
    Log.i("MAHDI","Screen width="+dpFromPx(this,width)+" dp");

}

public static float dpFromPx(final Context context, final float px) {
    return px / context.getResources().getDisplayMetrics().density;
}

public static float pxFromDp(final Context context, final float dp) {
    return dp * context.getResources().getDisplayMetrics().density;
}

اگر بخواهیم دیوایس ها را بر اساس عرض به dp تقسیم بندی کنیم:

320dp: a typical phone screen (240x320 ldpi, 320x480 mdpi, 480x800 hdpi, etc).
480dp: a tweener tablet like the Streak (480x800 mdpi).
600dp: a 7” tablet (600x1024 mdpi).
720dp: a 10” tablet (720x1280 mdpi, 800x1280 mdpi, etc).

و مثال:

res/layout/main_activity.xml           # For handsets (smaller than 600dp available width)
res/layout-sw600dp/main_activity.xml   # For 7” tablets (600dp wide and bigger)
res/layout-sw720dp/main_activity.xml   # For 10” tablets (720dp wide and bigger)

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

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

راهکار پیشنهادی

پیشنهاد خود گوگل این است که:

1. استفاده از wrap_content، match_parent و  dp برای مشخص کردن ابعاد در xml فایل های layout
2. عدم استفاده از واحد پیکسل آن هم بصورت هارد کد شده. ( یعنی ثابت :: مثلا ۱۰۰px )
3. عدم استفاده از AbsoluteLayout که البته منسوخ شده است.
4. فراهم کردن تصاویر جایگزین در سایزهای گوناگون برای صفحه نمایش های مختلف.

چطور طراحی را  پیاده سازی کنیم؟ تبدیل پیکسل از فتوشاپ به dp

بعد از دانستن مطالب بالا نوبت آن می رسد که بدانیم در طراحی واحدها را چگونه انتخاب کنیم تا پیداه سازی آن در گوشی بسیار راحت باشد؟ بهتر است بگوییم در این بخش می خواهیم ارتباط درستی با طراح داشته باشیم تا بعد از طراحی نیازی به سعی و خطا جهت بدست آوردن اندازه طرح داده شده نباشیم!

بسیار ساده است! ببینید آیا خودتان پیشنهادی دارید؟ روی این قضیه کمی تامل کنید و سپس ادامه مطلب را مشاهده فرمایید…

1. سایز گوشی که به عنوان معیار در دست دارید را به اینچ حساب کنید. ppi یا dpi آن هم مشخص است. ( مثلاً galaxy s6 557dpi است و اندازه آن ۴٫۵in در ۲٫۵in )
2. در فوتوشاپ یک فایل جدید به اندازه سایز گوشی با اینچ درست کنید با تراکم پیکسلی گوشی. ( یعنی ۵۵۷ pixel/inch )
3. حال هر طرحی زده شود هر پیکسل آن معادل یک dp است. بنابر این اگر طراح بخواهد فاصله ها را به پیکسل بدهد شما به راحتی می توانید همان اعداد را با واحد dp جایگزین کنید.
4. از آنجا که گوشی شما در منطقه xxxhdpi قرار دارد یعنی دارای ضریب ۴ است. البته سایز های به dp هیچ نیازی به تغییر سایز ندارند و کار دولوپر با استفاده از واحد dp تقریباً تمام است و از اینجا به بعد گرافیست باید فایل های جایگزین را با در نظر گرفتن ضریب برای دسته بسازد. یعنی برای بدست آوردن xxhdpi کافی است تمامی فایل ها را ضرب در ۳/۴ بکنیم. اگر تصویری داریم که سایز آن ۴۰۰ در ۴۰۰ است رای تغییر سایز آن برای فولدرهای دیگر به این صورت می شود و تمامی این زحمات به عهده گرافیست است:

مثلا اگر تصویری استفاده کردیم که سایز اصلی آن در photoshop  به ۳۴۰×۵۴۰ است برای تغییر سایز آن برای فولدرهای دیگر به این صورت می شود :

نکته: یک نکته ای که وجود دارد این است که اندازه های انتخاب شده با تقریب خوبی درهمه دستگاه ها یکسان است. بخاطر اینکه dp بطور تقریبی است. چرا دقیق نیست؟ دلیل این است که برای dpi ها از بازه استفاده کردیم.  یعنی گفته ایم از ۱۴۰dpi تا ۱۹۹dpi را یکی و mdpi در نظر بگیر و همچنین بازه های دیگر. بله اگر تراکم ما دقیقاً ۱۶۰dpi باشد یک پیکسل و یک dp برابر می شود. اما فرض کنید در گوشی متفاوت که هردو در بازه ۲۴۰dpi یعنی hdpi هستند و یکی در مرز بالا یعنی مثلا ۲۷۹dpi قرار دارد و دیگری در مرز پایین یعنی ۲۰۰dpi در همه اینها نیز یک پیکسل یک dp در نظر گرفته می شود که همین امر باعث اییجاد اندازه تقریبی می شود. می دانیم طبق تعریف های انجام شده هر دو دریک بازه قرار می گیرند و از یک فرمول تبعیت می کنند. حال اگر طرحی داشته باشیم ۳۰۰dp باشد با فرمول dp/dpi = inch * 2.5 = cm  در اولی ۳۰۰/۲۷۹=۲٫۶۸cm و در دومی ۳۰۰/۲۰۰=۳٫۷۵cm که این اختلاف حدود یک سانتی متر وجود دارد. درصورتی که قرار بود اگر از dp استفاده کنیم در همه جا اندازه نمایشی یکسان باشد! پس بدانید که اگر کمی اختلاف بود بخاطر همین تقریب است. البته از نظر گوگل این قضیه ایرادی نداشته و در این مقاله فرض را بر این می گذاریم که آن تغییر و خطای ناشی از بازه ها را نادیده گرفتیم.

جمع بندی

همانطور که ملاحظه کردید می توان طوری طراحی را انجام داد که آن طراحی در گوشی های گوناگون یکسان دیده شود. بحث دیگری که داریم این است که گاهی لازم است اندازه ها یکسان نباشد. فرض کنید با استفاده از مطالب یاد شده کاری کردیم که دکمه ما در همه صفحه ها به یک نسبت و کاملا مطابق طراحی شد. اما در یک تبلت ۱۰ اینچی آیا یک دکمه بزرگ معنی خواهد داشت؟ و یا اینکه فرض کنید طوری طراحی کردیم که ۱۰ عدد آیتم صفحه قرار گیرد. در گوشی مبدا ۱۰ آیتم بسیار مناسب و خوب است اما در یک صفحه کوچک ۱۰ تا ایتم باعث می شود که آنقدر کوچک باشند که دیدن و یا انتخاب آنها بسیار سخت خواهد شد! پس یکسان نگه داشتن سایز و نسبت همیشه درست نیست و گاهی اوقات باید کلا طراحی و سایز ها عوض شوند. یعنی در فولدرهای منابع، dimension و layout های مختلفی قرار گیرند.

منابع:

https://developer.android.com/guide/practices/screens_support.html

https://developer.android.com/guide/practices/screen-compat-mode.html

https://developer.android.com/guide/practices/screens-distribution.html

https://developer.android.com/guide/practices/ui_guidelines/icon_design_launcher.html

https://developer.android.com/training/multiscreen/screendensities.html

https://developer.android.com/guide/topics/resources/providing-resources.html

نوشته آیا یک dp یک pixel است؟ اولین بار در Mahdi Tajik پدیدار شد.

HCI (human-computer interaction) is the study of how people interact with computers and to what extent computers are or are not developed for successful interaction with human beings.

در HCI یکی از مهمترین مفاهیم  Usability یا قابلیت استفاده است که شامل اجزاء زیر است:

1. یادگیری: کاربران باید بتوانند راحت کار با سیستم را بیاموزند و یاد بگیرند.
2. بهره وری: با بهترین روش بهترین نتیجه را بدست آورد و باعث رضایت کاربر شود.
3. به یادسپاری: کاربر به راحتی بتواند به خاطر بسپارد و در برخورد های بعدی نحوه ارتباط را به یاد آورد.
4. کاهش نرخ خطا: خطا نه تنها کرش و پیغام خطا در سیستم است بلکه رسیدن به یک وضعیتی که کاربر نداند در کجا قرار گرفته است نیز خطا محسوب می شود و باید تا جای ممکن نرخ خطا کاهش پیدا کند.
5. رضایت شخصی: بالابردن رضایت شخصی در حد اعلاء.

قوانین طلایی اشنایدرمن در طراحی رابط کاربری

قوانین که در زیر مشاهده می کنید به قوانین اشنایدرمن معروفند که اصول کلی برای طراحی UI را بصورت زیر تعریف می کند که ما عوامل یادشده Usability را در تک تک قوانین آن برسی خواهیم کرد.

1. یکپارچگی: در تمامی سیستم از یک روش برای نمایش و یا ارتباط کاربر استفاده نماییم. مثلا اگر در یک بخش از برنامه بازگشت توسط دکمه خاصی باشد در تمامی برنامه برای بازگشت از همان روش استفاده نماییم. این قضیه هم باعث یادگیری بهتر می شود، هم بهره وری بالا می رود و هم اینکه بهتر به خاطر کاربر می ماند.
2. میانبر: به فکر همه کاربر ها باشید. هم کاربران جدید تازه وارد و هم کاربران حرفه ای. همانگونه که رابط کاربری ما باید بسیار گویا برای کاربران جدید باشد باید کلیدهای میانبری برای کاربران قدیمی بگذاریم تا بعد از مدتی برنامه کسل کننده نشود و بتوانند سریع تر به اهداف خود برسند.
3. دادن فیدبک به کاربر: وقتی اتفاقی دارد می افتد کاربر ازآن مطلع کنیم. مثلا کاربر فرم  اطلاعات را پر می کند و دکمه ثبت را می زند.  وقتی برنامه  درحال ارسال اطلاعات به سرور و منتظر بازگشت اطلاعات است باید پیغام لطفاً “منتظر باشید، دستور شما در حال اجرا است!” را به کاربر بدهیم. این باعث می شود رضایت شخصی بالابرود.
4. تایید کاربر: وقتی اتفاقات مهمی دارد رخ می دهد حتماً  تایید  مربوطه را بگیریم. “آیا مایلید تمامی فایل ها حذف شوند؟” و این باعث ایجاد کاهش نرخ خطا و رضایت شخصی بیشتر می شود.
5. از خطا جلوگیری کنید: تا جای ممکن جلوی بروز هرگونه خطا را بگیرید. چه خطای سیستمی چه خطایی که ممکن از ناشی استفاده نادرست کاربر از برنامه باشد. مثلا اگر قرار است در جایی فقط عدد وارد شود نوع فیلد ورودی با کنترل کننده عدد بگذارید که فرضاً اگر کاربر در فیلد مربوط به سن  “۱۹ سال” را نتواند وارد کند. این قلانون باعث افزایش بهره وری و رضایت شخصی بیشتر می شود.
6. امکان بازگشت: دکمه پشیمان شدم را برای اتفاقات مهم بگذاریم تا کاربر بتواند بعد از انجام کاری حساس و در صورت پشیمانی بتواند به وضعیت قبلی برگردد.
7. حسن کنترل به کاربر: کاربر همیشه باید حس کنترل روی برنامه داشته باشد نه اینکه برنامه او را کنترل کند. قابلیت شخصی سازی های گوناگون، ابزارهای در دسترس، اطلاع رسانی های کامل و بی نقض باعث افزایش این حس می شود.
8. حساب نکردن روی حافظه کوتاه مدت کاربر: باید تمام تلاش خود را در جهت ساده سازی روند انجام دستورات توسط برنامه بکارگیریم تا کاربر به سهولت با برنامه ارتباط برقرار کند. به عنوان مثال اگر قرار است کدفعال سازی را بصورت دستی وارد کند کد ۸ رقمی به او ندهیم و اگر ناچاراً ۸ رقمی است روند وارد کردن آن را اتوماتیک کنیم.

قانون فیتسfitt’s law

Faster to hit larger Targets closer to you  than  smaller targets further from you

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

قانون فیتس بصورت زیر است.  A همان فاصله یا d می باشد. طبق این قانون درجه سختی با اندازه ( عرض) آیتم رابطه معکوس و با فاصله مان تا آن رابطه مستقیمی دارد. هرچه درجه سختی (ID) بیشتر باشد دسترسی به آن آیتم سخت تر خواهد بود.

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

نتیجه نهایی به این صورت تفسیر کنید:

ID = Index of difficulty

A | d = distance

W = width of object

MT = Movement time to hit Target

TP = throughput   توان عملیاتی

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

انتخاب بین رنگ های بالا برایتان ساده تر است یا انتخاب از پلت رنگی زیر:

کاربران چگونه گوشی خود را دردست می گیرند

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

همانطور که ملاحظه می کنید بیشتر آمار ما برای کاربران راست دست است. زیرا آنها بیشترین سهم کاربران ما را تشکیل می دهند. حال با توجه به نحوه در دست گرفتن نقاط  صفحه را باتوجه به راحتی دسترسی به سه قسمت  Easy و OK و forbidden تقسیم می کنیم که به ترتیب به رنگ های سبز و زرد و قرمز می باشد. آیتم های پرکاربرد که زیاد لمس می شوند باید در  بخش Easy قرار گیرد. آیتم هایی که خیلی پر استفاده نیستند در OK و یا Forbidden قرار گیرند. حتی المقدور نباید آیتم ها را در ناحیه قرمز قرار داد، زیرا لمس کردن آنها بسیار سخت است. البته گاهی پیش می آید که آیتم کم کاربردی را در این بخش قرار دهیم. مثلا آیکون تنظیمات اگر قرار است در صفحه اول قرار گیرد با توجه به ارجاعات کم به آن ( شاید روزی یک بار یا کمتر) بهتر است در ناحیه قرمز قرار گیرد. مثلا گوشه بالا سمت چپ.

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

و این آمار برا چپ دست ها بصورت زیر است:

در سایز های مختلف گوشی بدین شکل تغییر می کند:

در تبلت بصورت زیر است:

و در تبلت بصورت افقی:

همچنین در سه مدل آیفون به شکل زیر است:

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

امیدوارم مطالب فوق مفید واقع شده باشد. اگر سوال یا نکته نظری داشتید کامنت بگذارید.

منبع: بایت کد

نوشته مفاهیم مهندسی رابط کاربر اولین بار در Mahdi Tajik پدیدار شد.

تفاوت های اصلی IntentService با Service در این است که بعد از ایجاد آن در Worker دیگری جدا از thread برنامه قرار می گیرد. برنامه به راحتی می تواند با آن ارتباط برقرار کند و خود IntentService نیز بعد از انجام وظایف محول شده بسته می شود و لازم نیست نگران هندل کردن آن باشیم. همانگونه مطلع هستید توسط Service می توانیم چندین task موازی داشته باشیم در صورتی که اگر چند نمونه از intentService تولید کنیم همگی در یک thread بصورت صف پشت هم قرار می گیرند تا پس از اتمام دیگری اجرا شوند و به نظر می رسد برای انجام یکسری دستورات batch بصورت متوالی و پشت سرهم هستند، بسیار مناسب باشد.

in short, a Service is a broader implementation for the developer to set up background operations, while an IntentService is useful for “fire and forget” operations, taking care of background Thread creation and cleanup

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

به مثال زیر توجه کنید: می خواهیم بعد از گرفتن ورودی توسط کاربر IntentService ای اجرا کنیم که کلاسی به نام  MyData ساخته و بعد از مقداردهی آن به برنامه بازگرداند و برنامه نیز در صورت باز بودن آن داده را نمایش دهد. برای ارتباط بین سرویس و برنامه از

BroadcastReceiver

Serializable

public class MyIntentService extends IntentService {

    public MyIntentService(){
        super("my intent service");

    }
    @Override
    protected void onHandleIntent(Intent intent) {

        String myName = intent.getStringExtra("NAME");
        SystemClock.sleep(1000);

        MyData myData = new MyData();
        myData.setId(110);
        myData.setName(myName);
        myData.setLasname("tajik");
        myData.setDate(DateFormat.format("dd/MM/yy h:mm:ss aa", System.currentTimeMillis()).toString());

        Intent broadCastIntent = new Intent();
        broadCastIntent.setAction("mahdi.broadcast.action");
        Bundle myboundle = new Bundle();
        myboundle.putSerializable("mahdi.data",myData);
        broadCastIntent.putExtra("mahdi.bundle",myboundle);

        LocalBroadcastManager myBroadCastManager = LocalBroadcastManager.getInstance(this);
        myBroadCastManager.sendBroadcast(broadCastIntent);

        Log.i("TAG", "onHandleIntent: name"+myName);
    }
}

کلاس  MyData به صورت زیر می باشد:

public class MyData implements Serializable {
    int Id;
    String name;
    String lasname;
    String date;

    public String getDate() {

        return date;
    }

    public void setDate(String date) {
        this.date = date;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getLasname() {
        return lasname;
    }

    public void setLasname(String lasname) {
        this.lasname = lasname;
    }

    public int getId() {
        return Id;
    }

    public void setId(int id) {
        Id = id;
    }
}

حال سرویس را در Manifest تعریف می کنیم:

<service android:name=".MyIntentService"></service>

برای ارتباط برقرار کردن از سرویس کافی است که Broadcast Receiver ای تعریف کنیم با فیلتری مشترک که در MainActivity باشد. همانطور که می دانید یکی از بهترین روش های ارتباط سرویس و برنامه استفاده از Broad Cast Receiver است. روش بدین صورت است که برنامه گوش خود را به فیلتر خاصی تیز می کند! (register) سپس سرویس نیز پیغامی با فیلتر موردنظر منتشر می کند. پس برنامه به صدای سرویس عکس العمل نشان داده و اطلاعات را گرفته و سپس نمایش می دهد. به همین سادگی.

public class MainActivity extends AppCompatActivity {

    BroadcastReceiver myReceiver;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        myReceiver = new BroadcastReceiver() {
            @Override
            public void onReceive(Context context, Intent intent) {
                Bundle myBoundle = intent.getBundleExtra("mahdi.bundle");
                MyData mData = (MyData) myBoundle.getSerializable("mahdi.data");
                Toast.makeText(MainActivity.this, "Received mData.name=" + mData.getName(), Toast.LENGTH_SHORT).show();
            }
        };
    }

    @Override
    protected void onStart() {
        super.onStart();
        LocalBroadcastManager.getInstance(this).registerReceiver(myReceiver, new IntentFilter("mahdi.broadcast.action"));
    }

    @Override
    protected void onStop() {
        super.onStop();
        LocalBroadcastManager.getInstance(this).unregisterReceiver(myReceiver);
    }

    public void startService(View v) {
        EditText edit = (EditText) findViewById(R.id.editText);
        String name = edit.getText().toString().trim();

        Intent i = new Intent(MainActivity.this, MyIntentService.class);
        i.putExtra("NAME", name);
        startService(i);

    }
}

بعد از لمس شدن دکمه شروع در صورتی که برنامه را نبسته باشید پیغام Toast را مشاهده خواهید کرد.

آزمایش کردن اجرای چند IntentService باهم نیز بسیار ساده است. کافی است  سرویس خودمان را چندبار  پشت سر هم اییجاد کنید و خواهید دید که هرکدام  بعد از ۵ ثانیه ( یعنی تمام شدن کارهای سرویس قبلی) اجرا خواهند شد. یعنی بصورت موازی نبوده و در صف قرار می گیرند.

در جواب یکی از دوستان سوالی پرسیده بودند که آیا این هم مانند سرویس در صورت بسته شدن برنامه اجرا می شود یا خیر، باید عرض کنم “بله”. IntentService هم مانند سرویس در صورت بسته بودن برنامه اجرا می شود. برای تست این قضیه می توانید

MainActivity

public class MainActivity extends AppCompatActivity {

    BroadcastReceiver myReceiver;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        myReceiver = new BroadcastReceiver() {
            @Override
            public void onReceive(Context context, Intent intent) {
                Bundle myBoundle = intent.getBundleExtra("mahdi.bundle");
                MyData mData = (MyData) myBoundle.getSerializable("mahdi.data");
                Toast.makeText(MainActivity.this, "Received mData.name=" + mData.getName(), Toast.LENGTH_SHORT).show();
            }
        };

        for(int i=0; i<10 ; i++){
            startService("name"+i);
        }
        this.finish();
    }

    @Override
    protected void onStart() {
        super.onStart();
        LocalBroadcastManager.getInstance(this).registerReceiver(myReceiver, new IntentFilter("mahdi.broadcast.action"));
    }

    @Override
    protected void onStop() {
        super.onStop();
        LocalBroadcastManager.getInstance(this).unregisterReceiver(myReceiver);
    }

    public void startService(String name) {
        EditText edit = (EditText) findViewById(R.id.editText);
//        String name = edit.getText().toString().trim();

        Intent i = new Intent(MainActivity.this, MyIntentService.class);
        i.putExtra("NAME", name);
        startService(i);

    }

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

BroadcastReceiver

Serializable

استفاده کردم. مطمئناً خیلی از دوستان آشنایی کامل دارند و استفاده می کنند. اما دوستانی که برایشان تازه است حتماً راجع به آنها خوانده و در صورت نیاز سوال بپرسند. امیدوارم مطالب مفید بوده باشد. درصورتی که سوال و یا نکته نظری داشتید کامنت بگذارید. خیلی ممنون.

منبع: بایت کد

نوشته کاربا IntentService و تفاوت آن با Service اولین بار در Mahdi Tajik پدیدار شد.

مطلبی که این جلسه قصد آموزش آن را دارم کار با سیستم مدیریت حساب داخلی اندروید می باشد. می خواهیم در یک پروژه عملی یک حساب کاربری دلخواه بسازیم و بعد از ثبت نام اولیه , تایید از سرور، برنامه با استفاده از حساب کاربری داخلی ایجاد شده بطور خودکار لاگین کند. با توجه به اینکه منابع زیادی در این رابطه حتی به انگلیسی موجود نمی باشد، امیدوارم این مطلب برایتان مفید واقع شود. در واقع مشکل از جایی شروع شد که خودم به دنبال پیداکردن جوابی برای آن بودم نهایتاً تجربه شخصی خودم را برایتان به اشتراک می گذارم. البته در آموزش امروز با اصول اولیه حساب کاربری آشنا خواهیم شد و اصل مطلب برای آموزش بعدیست!

This class provides access to a centralized registry of the user’s online accounts. The user enters credentials (username and password) once per account, granting applications access to online resources with “one-click” approval.

طبق تعریف رسمی اندروید: AccountManager کلاسی است که ثبت نام های آنلاین کاربر را متمرکز کرده و با توجه به اطلاعاتی که از کاربر نگهداری می کند( از قبیل نام کاربری و کلمه عبور)، ارتباط با آن (کاربر ثبت شده) و استفاده از منابع آن را توسط برنامه ها به آسانی فراهم می کند.

برای کار با AccountManager اندروید نیاز به سه آیتم اصلی داریم که هرکدام را ملاحظه خواهید کرد.

• سرویس ویژه مدیریت حساب
• فایل xml حاوی اطلاعات مربوط به حساب کاربری
• یک نمونه از کلاس AbstractَAccountAuthenticator

public class MyAthenticator extends AbstractAccountAuthenticator {
    
    public MyAthenticator(Context context) {
        super(context);
    }

    @Override
    public Bundle editProperties(AccountAuthenticatorResponse response, String accountType) {
        return null;
    }

    @Override
    public Bundle addAccount(AccountAuthenticatorResponse response, String accountType, String authTokenType, String[] requiredFeatures, Bundle options) throws NetworkErrorException {

        Log.i("MAHDI","on add account");
        return null;
    }

    @Override
    public Bundle confirmCredentials(AccountAuthenticatorResponse response, Account account, Bundle options) throws NetworkErrorException {
        return null;
    }

    @Override
    public Bundle getAuthToken(AccountAuthenticatorResponse response, Account account, String authTokenType, Bundle options) throws NetworkErrorException {
        return null;
    }

    @Override
    public String getAuthTokenLabel(String authTokenType) {
        return null;
    }

    @Override
    public Bundle updateCredentials(AccountAuthenticatorResponse response, Account account, String authTokenType, Bundle options) throws NetworkErrorException {
        return null;
    }

    @Override
    public Bundle hasFeatures(AccountAuthenticatorResponse response, Account account, String[] features) throws NetworkErrorException {
        return null;
    }
}

در این کلاس مشتق شده متدها بطور خودکار تولید می شوند و توضیح اینکه کار اصلی آن چه است برای آموزش بعدی و فقط این را بدانید که اجباری است. من  فقط در متد addAccount یک لاگ گذاشتم تا ببینید چه موقع فراخوانی می شود و بدانید اتفاقات این کلاس ارتباط مستقیمی به حساب کاربری دارد. مثلا هرجایی از Account-Manager استفاده کنیم و توسط آن اکانتی را اضافه کنید، متد addAccount در این کلاس فراخوانی می شود. ارتباط این کلاس با Account-manager توسط سرویسی است در پایین می بینید.
سرویس را بصورت زیر بسازید:

public class myService extends Service {
    @Nullable
    @Override
    public IBinder onBind(Intent intent) {

        MyAthenticator authenticator = new MyAthenticator(getBaseContext());
        return authenticator.getIBinder();
    }
}

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

<?xml version="1.0" encoding="utf-8"?>
<account-authenticator xmlns:android="http://schemas.android.com/apk/res/android"
    android:accountType="ir.mahditajik.testAppAccountType"
    android:icon="@mipmap/ic_launcher"
    android:smallIcon="@mipmap/ic_launcher"
    android:label="@string/app_name"/>

سپس لازم است تا سرویس تولید شده را در فایل Manifest  تعریف کرده و فایل account_data.xml را ضمیمه کنیم:

<service android:name=".MyService" android:exported="false">
    <intent-filter>
        <action android:name="android.accounts.AccountAuthenticator"/>
    </intent-filter>
    <meta-data
        android:name="android.accounts.AccountAuthenticator"
        android:resource="@xml/account_data"/>
</service>

حال تنها کاری که باید انجام دهیم استفاده از دستور accountmanageraddAccountExplicitly در هر جای دلخواه است.

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
        setSupportActionBar(toolbar);

        FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
        if (fab != null)
            fab.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View view) {
                    AccountManager accountManager = AccountManager.get(MainActivity.this); //this is Activity
                    Account account = new Account("MyAccount", "com.mahdi");

                    boolean success = accountManager.addAccountExplicitly(account, "password", null);
                    accountManager.setPassword(account, "mahditajik");
                    if (success) {
                        Log.d("mahdi", "Account created");

                    } else {
                        Log.d("mahdi", "Account creation failed. Look at previous logs to investigate");
                    }
                }
            });

    }


    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        // Inflate the menu; this adds items to the action bar if it is present.
        getMenuInflater().inflate(R.menu.menu_main, menu);
        return true;
    }

    @Override
    public boolean onOptionsItemSelected(MenuItem item) {
        // Handle action bar item clicks here. The action bar will
        // automatically handle clicks on the Home/Up button, so long
        // as you specify a parent activity in AndroidManifest.xml.
        int id = item.getItemId();

        //noinspection SimplifiableIfStatement
        if (id == R.id.action_settings) {
            return true;
        }

        return super.onOptionsItemSelected(item);
    }
}

خیلی خوب! شما موفق شدید با اجرای برنامه و لمس fab button حساب کاربری جدیدی از نوع “com.mahdi” ایجاد کنید که در آن نام کاربری و کلمه عبور قرار داده شده است. می توانید به تنظیمات گوشی رفته و حساب کاربری تولید شده را مشاهده کنید. امیدوارم آموزش براتون مفید بوده باشدو  در آموزش بعدی نحوه استفاده از این نام کاربری و کلمه عبور برای لاگین خودکار و همچنین اتفاقات و متد های MyAutenticator را بطور مفصل مورد برسی قرار خواهیم داد. درصورتی که نکته نظر یا سوالی داشتید کامنت کنید.

نوشته کار با Account-manager اندروید اولین بار در Mahdi Tajik پدیدار شد.

شاید استفاده از google map برای خیلی ها به یکی از بهترین روش های پیدا کردن آدرس مبدل شده باشد. بنده که به شخصه خیلی از این ابزار استفاده می کنم. یکی از ایراد های اساسی که ما ایرانی ها می توانیم به این برنامه وارد کنیم “آنلاین بون” است. یعنی در صورتی که به اینترنت متصل نباشید تقریبا این برنامه بلا استفاده خواهد بود. این مساله برای خیلی از ما که اینترنت موبایل پر سرعتی در دسترس نداریم و یا مثلا قصد استفاده از نقشه در مناطق کوهستانی و فاقد پوشش شبکه را داریم، معضل مهمی خواهد بود.

اما آیا راهی وجود دارد که قسمت خاصی از نقشه را برای استفاده در بعد، مثلا در جایی که اینترنت نداریم و یا سرعت کند است در گوشی ذخیره کنیم؟!

در نسخه های قدیمی تر google map این امکان وجود داشت تا شما  منطقه ای برای ذخیره آفلاین انتخاب کنید که متاسفانه در ورژن های جدید این گزینه خذف شده است! امروز می خواهم تکنیکی را به شما آموزش بدهم که توسط آن بتوانید قسمت خاصی از نقشه را برای استفاده در آینده ذخیره کنید.

در قدم اول برنامه google map را در جایی که ترجیها توسط wi-fi اینترنت دارید، اجرا کنید. قسمتی از نقشه که مدنظرتان هست را بیاورید . زوم لازم را انجام داده و اجازه دهید تا نقشه بصورت کامل باگیری شود. در قدم دوم در بخش جستجوی نقشه، عبارت “Ok maps” را بدون علامت نقل قول تایپ کرده و دکمه جستجو را لمس کنید. اگر درست عمل کرده باشید عبارت “save this map?” در بالای برنامه و دکمه “Save”در قسمت پایین برنامه ظاهر می گردد. در صورتی که منطقه انتخابی بیش از حد وسیع باشد به شما اخطار داده می شود و باید با زووم لازم منطقه را کوچک تر کنید. در قدم نهایی دکمه ذخیره را زده و با توجه به سرعت اینترنت شما، نقشه ذخیره می گردد.

درنهایت درجایی که دسترسی به اینترنت ندارید  google map نقشه های آفلاین شما بطور خودکار نمایش می دهد و می توانید با استفاده از GPS  موقعیت خود را روی نقشه دیده و جهت یابی لازم را انجام دهید.

امیدوارم این مطلب مفید بوده باشد.

نوشته ذخیره نقشه در گوگل مپ برای استفاده آفلاین در مناطق فاقد اینترنت اولین بار در Mahdi Tajik پدیدار شد.