هادی جامی هادی جامی
نظرات نظرسنجی‌ها
کدامیک از روش‌های زیر را برای تولید App های موبایل ترجیح می‌دهید؟ چرا؟
من از نسخه‌ای که دلفی برای تولید برنامه‌های برپایه android و ios در اختیار برنامه‌نویس قرار میده استفاده کردم، با تمام راحتی که در تولید برنامه موبایلی داشتم (البته در دلفی) ولی وقتی خواستم خروجی بگیرم کلا منصرف شدم، خروجی که با خود جاوا حدودن ۳ تا ۴ مگابایت میشد با دلفی نزدیک به ۳۰ مگابایت شد و خب منطقی نبود، تلاش‌هایی برای کاهش حجم کردم ولی بی نتیجه بود .
در نهایت شخصا معتقدم تا زمانی که ابزارهای بومی و مخصوص به خود سیستم عامل مثل همین جاوا برای android هست استفاده از سایر ابزارها خیلی جالب نیست مگر اینکه در آینده همون وضعیتی که جاوا در android داره رو به دست بیارن .
‫۸ سال و ۵ ماه قبل، سه‌شنبه ۱۱ خرداد ۱۳۹۵، ساعت ۲۲:۴۱
علی یگانه مقدم علی یگانه مقدم
نظرات مطالب
بررسی ORM های مناسب جهت استفاده در اندروید
برای کارها و برنامه‌های عادی و برنامه هایی که نیاز به پیاده سازی سریعتری دارند از اکتیو اندروید استفاده میکنم. پیاده سازی راحت و سریعی دارد و امکانات خوبی نیز دارد. هر چند فکر کنم در مرحله نگاشت‌ها کند عمل میکند به خصوص اگر بخواهید با دیتاهای زیادی سروکله بزنید.
ولی اگر قرار باشد برنامه ای حرفه ای‌تر نوشته شود به نظرم GreenDao انتخاب بهتری خواهد بود.
‫۷ سال و ۹ ماه قبل، یکشنبه ۳ بهمن ۱۳۹۵، ساعت ۰۲:۱۵
وحید نصیری وحید نصیری
مطالب
C# 8.0 - پیشنیاز و روش راه اندازی
پیشنیاز کار با C# 8.0

هرچند بسیاری از قابلیت‌های C# 8.0 در خود کامپایلر #C پیاده سازی شده‌اند، اما برای مثال قابلیتی مانند «پیاده سازی پیش‌فرض اینترفیس‌ها» نیاز به یک runtime جدید دارد که به همراه NET Core 3.0. ارائه می‌شود. بنابراین NET Full 4x. شاهد پیاده سازی C# 8.0 نخواهد بود. همچنین یک سری از قابلیت‌های C# 8.0 وابسته‌ی به NET Standard 2.1. و  netcoreapp3.0  هستند؛ مانند نوع‌های جدید System.IAsyncDisposable و یا System.Range. به همین جهت است که برای کار با C# 8.0، حتما نیاز به نصب NET Core 3.0. نیز می‌باشد و به روز رسانی کامپایلر #C کافی نیست.


چه نگارش‌هایی از Visual Studio از NET Core 3.0. پشتیبانی می‌کنند؟

مطابق مستندات رسمی موجود، یک چنین جدولی در مورد نگارش‌های مختلف NET Core. و نگارش‌های ویژوال استودیوهایی از که از آن‌ها پشتیبانی می‌کنند، وجود دارد:

.NET Core SDK .NET Core Runtime Compatible Visual Studio MSBuild Notes
2.1.5nn 2.1 2017 15 Installed as part of VS 2017 version 15.9
2.1.6nn 2.1 2019 16 Installed as part of VS 2019
2.2.1nn 2.2 2017 15 Installed manually
2.2.2nn 2.2 2019 16 Installed as part of VS 2019
3.0.1nn 3.0 (Preview) 2019 16 Installed manually

بنابراین فقط VS 2019 است که قابلیت پشتیبانی از NET Core 3.0. را دارد. به همین جهت اگر قصد دارید با ویژوال استودیو کار کنید، نصب VS 2019 برای کار با C# 8.0 الزامی است.


فعالسازی C# 8.0 در ویژوال استودیو 2019

در زمان نگارش این مطلب، NET Core 3.0. در حالت پیش‌نمایش، ارائه شده‌است. به همین جهت جزء یکپارچه‌ی VS 2019 محسوب نشده و باید جداگانه نصب شود:


- برای این منظور ابتدا نیاز است آخرین نگارش NET Core 3.0 SDK. را دریافت و نصب کنید.
- سپس از منوی Tools | Options، گزینه‌ی Projects and Solutions را انتخاب و در ادامه گزینه‌ی Use previews of the .NET Core SDK را انتخاب کنید.
- پس از آن، این SDK جدید NET Core. به صورت زیر قابل انتخاب خواهد بود:


البته انتخاب شماره SDK صحیح به تنهایی برای کار با C# 8.0 کافی نیست؛ بلکه باید شماره‌ی زبان مورد استفاده را نیز صریحا انتخاب کرد:


برای اینکار بر روی پروژه کلیک راست کرده و گزینه‌ی Properties آن‌را انتخاب کنید. سپس در اینجا در برگه‌ی Build، بر روی دکمه‌ی Advanced کلیک کنید تا بتوان شماره نگارش زبان را مطابق تصویر فوق انتخاب کرد. در اینجا بجای C# 8.0 (beta)، گزینه‌ی unsupported preview را نیز می‌توانید انتخاب کنید.

یک نکته: خلاصه‌ی تمام این مراحل، منوها و تصاویر، همان تنظیمات فایل csproj است که در ادامه بررسی می‌کنیم.


فعالسازی C# 8.0 در VSCode

مدت‌ها است که برای کار با NET Core. نیازی به استفاده‌ی از نگارش کامل ویژوال استودیو نیست. همینقدر که VSCode را به همراه افزونه‌ی #C آن نصب کرده باشید، می‌توانید برنامه‌های مبتنی بر NET Core. را بر روی سیستم عامل‌های مختلفی که NET Core SDK. بر روی آن‌ها نصب شده‌است، توسعه دهید.
پشتیبانی ابتدایی از C# 8.0، با نگارش v1.18.0 افزونه‌ی #C مخصوص VSCode ارائه شد. بنابراین هم اکنون اگر آخرین نگارش آن‌را نصب کرده باشید، امکان کار با پروژه‌های NET Core 3.0 و C# 8.0 را نیز دارید.
بنابراین در اینجا به صورت خلاصه:
- ابتدا باید NET Core 3.0 SDK. را به صورت جداگانه‌ای دریافت و نصب کنید.
- سپس آخرین نگارش افزونه‌ی #C مخصوص VSCode را نیز نصب کنید.
- در آخر، یک پوشه‌ی جدید را ایجاد کرده و در خط فرمان دستور dotnet new console را صادر کنید. این دستور بر اساس آخرین شماره نگارش SDK نصب شده، یک پروژه‌ی جدید کنسول را ایجاد می‌کند که ساختار فایل csproj آن به صورت زیر است:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>
</Project>
همانطور که مشاهده می‌کنید، TargetFramework را به آخرین SDK نصب شده، تنظیم کرده‌است (معادل دومین تصویر این مطلب). مرحله‌ی بعد، تنظیم شماره نگارش زبان آن است. برای این منظور یکی از دو حالت زیر را می‌توان انتخاب کرد:
- یا معادل همان گزینه‌ی unsupported preview در تصویر سوم این مطلب:
<Project Sdk="Microsoft.NET.Sdk"> 
   <PropertyGroup> 
      <OutputType>Exe</OutputType> 
      <TargetFramework>netcoreapp3.0</TargetFramework> 
      <LangVersion>preview</LangVersion> 
   </PropertyGroup>
 </Project>
- و یا تعیین صریح شماره نگارش C# 8.0 (beta) به صورت زیر:
<Project Sdk="Microsoft.NET.Sdk"> 
   <PropertyGroup> 
      <OutputType>Exe</OutputType> 
      <TargetFramework>netcoreapp3.0</TargetFramework> 
      <LangVersion>8.0</LangVersion> 
   </PropertyGroup>
</Project>

یک نکته: در اینجا نمی‌توان LangVersion را به latest تنظیم کرد؛ چون C# 8.0 هنوز در مرحله‌ی بتا است. زمانیکه از مرحله‌ی بتا خارج شد، مقدار پیش‌فرض آن دقیقا latest خواهد بود و ذکر صریح آن غیر ضروری است. انتخاب latest در اینجا به latest minor version یا همان نگارش C# 7.3 فعلی (آخرین نگارش پایدار زبان #C در زمان نگارش این مطلب) اشاره می‌کند.



Rider و پشتیبانی از C# 8.0

Rider 2019.1 نیز به همراه پشتیبانی از C# 8.0 ارائه شده‌است و می‌تواند گزینه‌ی مطلوب دیگری برای توسعه‌ی برنامه‌های مبتنی بر NET Core. باشد.


نصب NET Core 3.0 SDK. و عدم اجرای برنامه‌های پیشین

یکی از مزایای کار با NET Core.، امکان نصب چندین نوع مختلف SDK آن، به موازت هم است؛ بدون اینکه بر روی یکدیگر تاثیری بگذارند. البته این نکته را باید درنظر داشت که برنامه‌های NET Core. بدون وجود فایل مخصوص global.json در پوشه‌ی ریشه‌ی آن‌ها، همواره از آخرین نگارش SDK نصب شده، برای اجرا استفاده خواهند کرد. اگر این مورد بر روی کار شما تاثیرگذار است، می‌توانید شماره SDK مورد استفاده‌ی برنامه‌ی خود را قفل کنید، تا SDKهای جدید نصب شده، به عنوان SDK پیش‌فرض برنامه‌های پیشین، انتخاب نشوند. بنابراین ابتدا لیست SDKهای نصب شده را با دستور زیر پیدا کنید:
> dotnet --list-sdks
سپس برای پروژه‌های قدیمی خود که فعلا قصد به روز رسانی آن‌ها را ندارید، یک فایل global.json را به صورت زیر‌، در ریشه‌ی پروژه تولید کنید:
> dotnet new globaljson --sdk-version 2.2.300
> type global.json
در اینجا 2.2.300 یکی از شماره‌هایی است که توسط دستور dotnet --list-sdks یافته‌اید و پروژه‌ی قبلی شما بر اساس آن کار می‌کند.
‫۵ سال و ۴ ماه قبل، دوشنبه ۶ خرداد ۱۳۹۸، ساعت ۱۸:۰۵
وحید نصیری وحید نصیری
اشتراک‌ها
Visual Studio 2017 15.5.5 منتشر شد

Issues Fixed in this Release
Xamarin app throws Cannot access a disposed object. Object name: 'MobileAuthenticatedStream'error.
Xamarin.Android app throws ClassNotFoundException when deriving from Application class.
Upgrading may cause previously installed Windows and Android SDKs to be uninstalled.
Bumped JDK 8 to the latest version to avoid download failures from Oracle website.
 

Visual Studio 2017 15.5.5 منتشر شد
‫۶ سال و ۸ ماه قبل، جمعه ۶ بهمن ۱۳۹۶، ساعت ۱۲:۱۸
امیر توکلی امیر توکلی
نظرات مطالب
اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity
چطور میتوانیم با استفاده از ASP.NET Core Identity در موبایل لاگین کنیم. یعنی بخوایم برنامه نویسی اندروید انجام بدیم و با استفاده از Api لاگین کنیم و یک سری کارهایی انجام بدیم
‫۶ سال و ۶ ماه قبل، دوشنبه ۳ اردیبهشت ۱۳۹۷، ساعت ۱۳:۴۲
یاسر مرادی یاسر مرادی
نظرات مطالب
توسعه برنامه های Cross Platform با Xamarin Forms & Bit Framework - قسمت چهارم
دو برنامه Mono Shared Runtime و Xamarin Android Support هستن. این دو، آیکون ای در Home Screen گوشی/امولاتور شما اضافه نمی‌کنند، بلکه فقط در قسمت Settings سیستم عامل، در جایی که تمامی App‌ها لیست شده اند، دیده می‌شوند. مطمئنا هر دو رو دارید که الآن تونستید دیباگ کنید. این که تغییر آنی Xaml روی امولاتور کار می‌کنه، ولی روی گوشی نه، احتمالا به خاطر این هست که گوشی و کامپیوتر تو یه شبکه نیستن، یا Firewall ای چیزی در بین هست. اعمال آنی تغییرات CSharp هم مختص UWP هست و در Android/iOS کار نمی‌کنه.
‫۵ سال و ۸ ماه قبل، شنبه ۲۹ دی ۱۳۹۷، ساعت ۱۰:۲۹
علی یگانه مقدم علی یگانه مقدم
مطالب
توزیع کلاس‌های اندرویدی با استفاده از Gradle قسمت اول
یکی از روش‌هایی که امروزه مورد استقبال برنامه نویسان اندروید و جاوا قرار گرفته‌است، استفاده از یک سیستم DSL به نام Gradle (+) است. ابتدا در سیستم‌های Apache Ant (+) و Maven (+) مورد استفاده قرار می‌گرفت، ولی با جمع کردن نقاط ضعف آن دو سیستم، و رفع عیوب آن‌ها و افزودن مزیت‌های جدید، Gradle ایجاد شد. یکی از استفاده‌هایی که به شدت مورد استفاده‌ی برنامه نویسان اندروید قرار می‌گیرد، استفاده از یک سیستم توزیع برای کلاس‌های اندرویدی است. اگر امروزه به خیلی از سورس‌های قرار گرفته بر روی گیت هاب، نگاه کنید، به غیر از روش افزودن آن سورس به پروژه به عنوان ماژول، روش دیگری نیز وجود دارد که آن، استفاده از سیستم توزیع Gradle است. استفاده از این روش محبوبیت زیادی دارد و بسیار هم راحت‌تر است از افزودن یک سورس به پروژه.

برای افزودن یک ماژول به پروژه از طریق گریدل، به صورت زیر اقدام می‌کنیم:
هر ماژول شامل یک فایل به نام build.gradle است که تنظیمات سطح آن ماژول را به عهده دارد و پروژه نیز یک build.gradle  دارد که تنظیمات آن در سطح پروژه صورت می‌گیرد. برای اقزودن سورس در سطح یک ماژول لازم است که تعدادی خط کد را که معرف و آدرس آن سورس را دارد، به فایل build.gradle اضافه کنیم. به عنوان مثال برای سورس Active Android را که یک ORM عالی در سطح اندروید به شمار می‌آید، به ماژولمان اضافه می‌کنیم:

dependencies {
    compile 'com.michaelpardo:activeandroid:3.1.0-SNAPSHOT'
}
ولی یک سوال پدید می‌آید که این خط کوتاه که تنها شامل نام و نسخه‌ی کتابخانه است، چگونه می‌تواند آدرس آن سورس را به دست بیاورد؟ در این نوشتار قصد داریم این مساله را بررسی کرده و بدانیم که این سورس‌ها چگونه به این سیستم توزیع اضافه شده‌اند.

سوال : اندروید استودیو، کتابخانه‌های اندرویدی را از کجا دانلود می‌کند؟
Apache Maven یک سیستم آزاد است که برای توزیع کتابخانه‌ها مورد استفاده قرار می‌گیرد. سرورهای این سیستم شامل یک مخزن maven هستند که کتابخانه‌ها در آن قرار می‌گیرند و شناسه‌ی دسترسی به آن کتابخانه از طریق همان شناسه‌ای است که شما در build.gradle تعریف می‌کنید. به طور عادی دو سرور استاندارد برای اینکار وجود دارند که یکی از آن‌ها jcenter و دیگری mavenCnteral است. البته سرورهای دیگری نیز وجود دارند، یا اینکه حتی خودتان هم می‌توانید میزبانی را به عهده بگیرید و یا بعضی از شرکت‌ها برای خود مخزنی جداگانه دارند.

JCenter
این سرور که یک مخزن maven است، توسط Bintray میزبانی می‌شود که می‌توانید آن را در این آدرس بیابید. برای اینکه شناسه‌های gradle مربوط به این سرور در اندروید استودیو دانلود شود، نیاز است خط زیر را به build.gradle سطح پروژه اضافه کنید:
allprojects {
    repositories {
        jcenter()
    }
}

MavenCentral
این مخزن توسط Sonatype.org میزبانی می‌شود که کل مخزن آن را می‌توانید در این آدرس بیابید. برای دسترسی به مخازن این سرور نیاز است خطوط زیر را به gradle سطح پروژه اضافه کنید:
allprojects {
    repositories {
        mavenCentral()
    }
}
موقعی که شما شناسه‌ی گریدل را اضافه می‌کنید، حتما باید دقت کنید مخزن آن کجا قرار گرفته است؟ آیا در یکی از آدرس‌های بالاست یا حتی می‌تواند در هر دو آدرس بالا قرار گرفته باشد؛ یا مخزنی غیر از مخازن بالاست.

به عنوان مثال Twitter's Fabric.io خودش کتابخانه‌ی خودش را میزبانی می‌کند و مخزن آن در این آدرس https://maven.fabric.io/public قرار گرفته است و برای افزودن این کتابخانه به پروژه نیاز است مسیر زیر طی شود: 
//project build.gradle
repositories {
    maven { url 'https://maven.fabric.io/public' }
}

//module build.gradle
dependencies {
    compile 'com.crashlytics.sdk.android:crashlytics:2.2.4@aar'
}

سوال : کدامیک از مخازن بالا را انتخاب کنیم؟
اینکه کدامیک را انتخاب کنیم مساله ای است که به خودتان مرتبط است و هر دو برای یک هدف ایجاد شده‌اند و آن میزبانی کتابخانه‌های جاوا و اندرویدی است. بسیاری از توسعه دهندگان از هر دو استفاده می‌کنند؛ ولی بعضی‌ها هم تنها یکی از آن دو را بر می‌گزینند. اندروید استودیو در نسخه‌های اولیه‌ی خود به طور پیش فرض mavencenteral را صدا میزد و به طور پیش فرض در buil.gradle پروژه، آن را معرفی کرده بود. ولی مساله ای که در این بین بود، این بود که این مخزن چندان به مذاق توسعه دهندگان خوش نمی‌آمد و کمی کار با آن دشوار و سخت بود. لذا تیم اندروید بنا به دلایلی مثل آن و موارد امنیتی و ... و اینکه توسعه دهندگان بیرونی بیشتر از jcenter استفاده می‌کردند، آن هم به سمت jcenter رفتند که در ورژن‌های فعلی اندروید استودیو می‌توانید ببینید که کتابخانه‌ی پیش فرض تغییر یافته است و ()jcenter به جای ()mavencentral صدا زده می‌شود.

دلایل مهاجرت از mavencentral به jcenter:

  1. سیستم jcenter از طریق یک CDN عمل می‌کند که در این صورت می‌تواند تجربه‌ی خوبی از سرعت بهتر را برای توسعه دهندگان به همراه داشته باشد.
  2. کتابخانه‌های jcenter بسیار بیشتر از mavencentral هستند؛ تا جایی که می‌توان گفت اکثر کتابخانه‌هایی که روی mavencenteral پیدا می‌شوند، روی jcenter هم هست و jcenter بزرگترین مخزن به شمار می‌آید.
  3. آپلود کتابخانه بر روی jcenter بسیار راحت‌تر است و نیاز به کار پیچیده‌ای ندارد.
در این نوشتار سعی داریم ابتدا کتابخانه‌ی AndroidBreadCrumb را بر روی jcenter آپلود کنیم و سپس با استفاده از روش آسانتری آن را به سمت mavenCentral بفرستیم.

بررسی قسمت‌های یک شناسه Gradle

هر شناسه شامل سه قسمت می‌شود:
GROUP_ID:ARTIFACT_ID:VERSION
قسمت اول نام پکیج است که به آن Group_ID می‌گویند و می‌تواند خانواده‌ای از یک پکیج را نیز مشخص کند. سپس قسمت Artifact، نامی است که بر روی پروژه‌ی خود گذاشته‌اید و سپس ورژن است که در قالب x.y.z معرفی می‌شود و در صورت اختیار می‌توانید عباراتی مثل beta- و snapshot- را هم داشته باشید.
کتابخانه‌های زیر، از یک خانواده هستند که به راحتی می‌توانید آن‌ها را از هم تشخیص دهید:
dependencies {
  compile 'com.squareup:otto:1.3.7'
  compile 'com.squareup.picasso:picasso:2.5.2'
  compile 'com.squareup.okhttp:okhttp:2.4.0'
  compile 'com.squareup.retrofit:retrofit:1.9.0'
}
پس نحوه‌ی دریافت کتابخانه‌ها به این شکل است که ابتدا اندروید استودیو به ترتیب مخازن معرفی شده‌ی در سطح پروژه را چک می‌کند و از طریق شناسه‌ی آن‌ها بررسی می‌کند که آیا این کتابخانه اینجا موجود است، یا خیر و اگر موجود بود آن را دانلود می‌کند.

شناخت فایل‌های AAR
همانطور که می‌دانید فرمت فایل‌های بایت کدی جاوا JAR می‌باشد که هم توسط جاوا و هم اندروید پشتیبانی می‌شود. ولی در صورتیکه کلاس شما یک پروژه‌ی اندرویدی باشد، نمی‌توانید آن را در قالب یک فایل JAR منتشر کنید. چرا که که کلاس اندرویدی می‌تواند شامل فایل مانیفست، منابع و ... باشد که در فایل JAR جایی برای آن‌ها مهیا نشده است. به همین علت فایل‌های نوع AAR برای اینکار مهیا شده‌اند که این فایل در واقع یک فایل زیپ است که محتویات مورد نظر داخل آن قرار گرفته است و یکی از آن فایل Classes.jar برای کدهاست و مابقی آن به شرح زیر است:
- /AndroidManifest.xml (الزامی)
- /classes.jar (الزامی )
- /res/ (الزامی )
- /R.txt (الزامی )
- /assets/ (اختیاری)
- /libs/*.jar (اختیاری )
- /jni/<abi>/*.so (اختیاری )
- /proguard.txt (اختیاری )
- /lint.jar (اختیاری )

در مقاله‌ی بعدی کار را با jcenter آغاز می‌کنیم.
‫۸ سال و ۱۲ ماه قبل، شنبه ۹ آبان ۱۳۹۴، ساعت ۲۳:۳۵
یاسر مرادی یاسر مرادی
مطالب
تفاوت Desktop Application با Web Application
در هنگام گفتگو با افراد مختلفی که در پروژه‌های توسعه نرم افزار، نقش‌های مختلفی را دارا می‌باشند، یکی از جالب‌ترین و اساسی‌ترین بحث‌ها تفاوت بین Desktop App و Web App می‌باشد، و این که پروژه بر اساس کدام مدل باید نوشته شود.

در اینترنت و در منابع معتبر، تفسیر‌های متفاوتی از این دو وجود دارد، که گاه دقیقا با نظر من یکی بوده و گاه تا 180 درجه بر عکس هستند، آنچه که در ادامه می‌خوانید می‌تواند لزوما نظر شما نباشد.
گروهی از افراد بر این باور هستند که اجرای برنامه در محیط مرورگر (ظاهر مرورگر و نه Sandbox آن)، یکی از ملاک‌های ما بین Desktop App  و Web App است، گروهی دیگر نیز اجرا شدن برنامه بر روی بستر اینترنت و یا شبکه‌ی محلی را جزو ملاک‌ها می‌دانند، و گروهی دیگر نیز زبان برنامه نویسی برنامه را ملاک می‌دانند، برای مثال اگر با HTML/JS باشد Web App است، اگر نه Desktop App است.
اما آنچه که در عمل می‌تواند تفاوت بین یک Desktop App را با یک Web App مشخص کند، رفتار و عملکرد خود آن برنامه است، نه بستر اجرای آن و این که آن رفتار منتج شده از چه کدی و چه زبان برنامه نویسی ای است.
اگر کمی دقیق به مطلب نگاه کنیم، می‌بینیم این که یک برنامه در چارچوب ظاهری یک مرورگر (نه Sandbox آن) اجرا شود، اصلا مقوله ای اهمیت دار نیست، کما این که برای مثال Silverlight اجازه می‌دهد، برنامه هم در داخل مرورگر و هم در بیرون از آن اجرا شود، و این کار با یک کلیک امکانپذیر است، آیا با همین یک کلیک برنامه از Web App به Desktop App تبدیل می‌شود یا بالعکس ؟
آیا یک برنامه مبتنی بر دلفی که تا همین یک ساعت پیش بر روی شبکه محلی در حال اجرا بوده، با انتقال پیدا کردن آن بر روی شبکه‌ی اینترنت، تبدیل به یک Web App می‌شود؟
آیا اگر ما با HTML/JS یک برنامه Native برای ویندوز فون بنویسیم که تک کاربره آفلاین باشد و اصلا سروری هم نداشته باشد، آیا Web App نوشته ایم ؟
اصلی‌ترین تفاوت مابین Web App و Desktop App که به تفاوت در عملکرد آنها و مزایا و معایب آنها منجر می‌شود، این است که انجام کارهایی که اپراتور با آنها در سمت کلاینت و سیستم مشتری سر و کار دارد، در کجا صورت می‌پذیرد؟
برای مثال در نظر بگیرید که یک دیتاگرید داریم که دارای Paging است، و ما از Page اول به Page بعدی می‌رویم، در یک Desktop App تنها اطلاعات از سرور گرفته می‌شود، و ترسیم خطوط و ستون‌ها و ردیف‌ها و ظاهر نمایشی دیتاگرید بر عهده کلاینت است، برای مثال اگر ستون قیمت داشته باشیم، و بخواهیم برای ردیف هایی که قیمت آنها زیر 10000 ریال است، قیمت به شکل سبز رنگ نمایش داده شود و برای بقیه ردیف‌ها به رنگ قرمز باشد، پردازش این مسئله و این if به عهده کلاینت است، اما در یک Web App، علاوه بر اطلاعات، تعداد زیادی tag‌های مختلف، مانند table - tr - td و ... نیز به همراه اطلاعات آورده می‌شوند، که وظیفه نمایش ظاهری اطلاعات را بر عهده دارند، و آن if مثال ما یعنی رنگ سبز و قرمز در سمت سرور مدیریت شده است، و کلاینت در اینجا نمایش دهنده‌ی آن چیزی است که به صورت آماده از سرور آورده شده است.
در برنامه‌های Desktop آنچه که در سمت سرور وجود دارد، برای مثال یک WCF Service یا ASP.NET Web API است که فقط به رد و بدل کردن اطلاعات می‌پردازد، اما در Web App‌ها در سمت سرور ASP.NET Web Forms، ASP.NET MVC و PHP وجود دارند که علاوه بر اطلاعات برای کلاینت شما ظاهر صفحات را نیز آماده می‌کنند، و ظاهر اصلی صفحات از سمت سرور به سیستم مشتری ارسال می‌شوند، اگر چه که ممکن است در سمت کلاینت تغییراتی را داشته باشند.
به هر میزان رفتار برنامه ما شبیه به حالت اول باشد، برنامه ما Desktop App بوده و به هر میزان برنامه ما به حالت دوم نزدیک‌تر باشد، برنامه ما Web App است.
مزیت اصلی Web App‌ها در عدم انداختن بار زیاد بر روی دوش کلاینت‌های بعضا نحیف بوده، و عملا کلاینت به علت این که کار خاصی را انجام نمی‌دهد، پیش نیاز نرم افزاری و یا سخت افزاری خاصی احتیاج ندارد، و این مورد Web App‌ها را به یک گزینه ایده آل برای وب سایت هایی تبدیل کرده است که با عموم مردم در ارتباطند، زیرا که امکان ارائه آسان برنامه وجود دارد و تقریبا همه می‌توانند از آن استفاده کنند.
با توجه به شناخت عموم از برنامه‌های Web App به توضیح بیشتر برنامه‌های Desktop App می‌پردازم.
مزیت اصلی Desktop App‌ها در سرعت عمل بالاتر(به علت این که فقط دیتا را رد و بدل می‌کند)، توانایی بیشتر در استفاده از منابع سیستمی مانند سرویس نوشتن، و امکانات محلی مانند ارائه Notification و ... است، و در کنار آن برای مثال یک Desktop App می‌تواند به نحوی طراحی شود که به صورت Offline نیز کار کند.
این مزیت‌ها باعث می‌شود که Desktop App‌ها گزینه ای مناسب برای برنامه‌های سازمانی باشند.
ضعفی که از گذشته در Desktop App‌ها وجود داشته است، که البته به معماری Desktop App بر نمی‌گردد، بلکه متاثر از امکانات است، عدم Cross Platform بودن آنها بوده است، تا آنجا که Desktop App در نظر خیلی از افراد همان نوشتن برنامه برای سیستم عامل ویندوز است.
با توجه به رویکرد جدی ای که در طول دو سال اخیر برای نوشتن برنامه Desktop App به شکل Cross Platform رخ داده است، خوشبختانه این مشکل حل شده است و اکنون لااقل دو راهکار جدی برای نوشتن یک برنامه Cross Platform با ویژگی‌های Desktop وجود دارد، که یکی از آنها راه حل‌های مبتنی بر HTML/JS است و دیگری راه حل‌های مبتنی بر C#/XAML
در راه حل‌های مبتنی بر HTML/JS در صورتی که شما برنامه را به شکل Web App طراحی نکرده باشید، و برای مثال در آن از ASP.NET Web Forms و ASP.NET MVC، PHP و ... استفاده نکرده باشید، می‌توانید یک خروجی کاملا Native با تمامی ویژگی‌های Desktop App برای انواع پلتفرم‌ها بگیرید.
استفاده از فریم ورک هایی که با طراحی Desktop App سازگار هستند، مانند Angular JS، Kendo UI و Ext JS، Jay-data و ... و استفاده از مدل طراحی Single Page Application می‌تواند سیستم کدنویسی ای ساده را فراهم آورد، که در آن شما با یک بار نوشتن برنامه می‌توانید خروجی اکثر پلتفرم‌های مطرح را داشته باشید، اعم از ویندوز فون، اندروید، iOS و ویندوز
امروزه حتی مرورگر‌ها با فراهم آوردن امکاناتی مانند Client side databases و Manifest based deployment اجازه نوشتن برنامه Desktop با HTML/JS را که حتی می‌تواند Offline کار کند را به شما ارائه می‌کنند.
در کنار این راهکار، استفاده از C#/XAML برای نوشتن برنامه برای اکثر پلتفرم‌های مطرح بازار اعم از اندروید، iOS و Windows Phone و ویندوز، نیز به عنوان راهکاری دیگر قابلیت استفاده را دارا است.
حرکت پر شتاب و پر انرژی جهانی برای توسعه Cross Platform Desktop Development، خوشبختانه توانسته است تا حد زیادی امتیاز نوشتن برنامه‌های Desktop را در سیستم‌های Enterprise بالا ببرد.
‫۱۰ سال و ۴ ماه قبل، جمعه ۲۰ تیر ۱۳۹۳، ساعت ۱۷:۱۵