میمون آتشین شروع کنید

2013/03/06 12:46 بعد از ظهر

من به دلیل عدم وجود کامپوننت مرورگر در FireMonkey بسیار متضرر شدم. پروژه معروف Delphi Chromium Embedded شامل پشتیبانی از FMX در آخرین نسخه بود. اما علیرغم اینکه زمان زیادی گذشته است، نویسنده عجله ای برای اضافه کردن پشتیبانی FMX2 ندارد. در نهایت مجبور شدم همه چیز را به دست خودم بگیرم.

کامپوننت TCChromiumFMX از اسمبلی رسمی در FireMonkey (در XE2) به خوبی کار می کند، اما حتی در FMX2 نیز کامپایل نمی شود. باید کمی نحوه کارکردش را بفهمم و درستش کنم. خوشبختانه هیچ تغییر اساسی لازم نبود.

در FMX2 دو موردی که کامپوننت به آن نیاز دارد تغییر کرده است.

اول، TBitmap دیگر ویژگی های ScanLine و StartLine را ندارد. دسترسی مستقیم به محتوای TBitmap دوباره طراحی شده است (من نمی دانم چرا؟) و اکنون از طریق کلاس TBitmapData در دسترس است که روش TBitmap.Map را برمی گرداند.

خوب، دومین و شناخته شده تر - پلتفرم .* دیگر وجود ندارد، اکنون باید رابط مورد نظر را از طریق TPlatformServices.GetPlatformService دریافت کنید. همه چیز در اینجا بسیار ساده است و هیچ مشکلی وجود ندارد.

من آن را با نبوغ خاصی آزمایش نکردم، اما این مؤلفه برای اهداف من کاملاً مناسب است - می توانید سایت ها را از طریق آن مشاهده کنید. آن را دانلود کنید. با این حال، شاید ویرایش های خود را برای نویسنده ارسال کنم، شاید لازم بداند که آنها را به نسخه رسمی اضافه کند.

2012/07/30 2:43 ق.ظ

Jason Southwell پیشنهاد می‌کند مجموعه‌ای از بسته‌بندی‌های FireMonkey را برای کنترل‌های بومی Windows/OSX توسعه دهد و برای این کار پول جمع‌آوری می‌کند. او قصد دارد برای شروع 20000 دلار جمع آوری کند.

ایده روشن است. اجزای FireMonkey موجود با استفاده از ابزارهای دلفی تقریباً از ابتدا رندر می‌شوند، که از یک سو تا حد زیادی از پلتفرم متقابل آنها اطمینان می‌دهد، اما از سوی دیگر، در نتیجه، مؤلفه‌هایی دریافت می‌کنیم که در هر دو عملیات پشتیبانی شده در حال حاضر کاملاً طبیعی به نظر نمی‌رسند. سیستم های. و این خیلی بد نیست - علاوه بر ظاهر، شما باید به طور مستقل منطق این اجزا را توسعه دهید. به عنوان مثال، RichEdit بسیار پیچیده است و تکرار منطق آن در FireMonkey کار بی اهمیتی نیست. VCL و CLX هر دو دوچرخه را اختراع نکردند، بلکه از دوچرخه های آماده استفاده کردند.

و حالا خبر بد. همه چیز در زمان اجرا کار می کند، اما من هیچ راهی برای اضافه کردن نوع برگه جدید خود به Items Designer پیدا نکردم. و به نظر می رسد که همه کنترل های لیست مشکل یکسانی دارند: TListBox، TGrid و غیره. در ابتدا رویکرد اجرای آنها را خیلی دوست داشتم، اما اکنون حتی به نوعی به آن شک دارم. یک جستجوی اینترنتی نشان داد که من با این مشکل تنها نیستم.

Help بی صدا است، من همچنین چیزی در کد پیدا نکردم. واقعا راهی نیست؟ این بسیار آزاردهنده خواهد بود.

بیش از سه سال از زمانی که بخش CodeGear مسئول ایجاد ابزارهای مشهور جهانی مانند Delphi، C++Builder و JBuilder و همچنین Interbase DBMS، بخشی از Embarcadero Technologies می گذرد، شرکتی که به دلیل طراحی و مدیریت پایگاه داده خود شناخته شده است. ابزارها و دو سال از زمانی که در صفحات مجله خود بحث کردیم که در توسعه ابزارهایی که در بین توسعه دهندگان روسی بسیار محبوب هستند چه انتظاری داریم. ما از دیوید اینترسیمون، معاون روابط توسعه‌دهنده و مبشر ارشد Embarcadero Technologies، و Kirill Rannev، رئیس دفتر نمایندگی Embarcadero Technologies در روسیه پرسیدیم. برای جوانترین خوانندگان ما، به شما اطلاع خواهیم داد که این با اولین مصاحبه ای که دیوید و کریل با ComputerPress انجام می دهند فاصله زیادی دارد - همکاری ما برای دهه دوم ادامه دارد. و برای همین چند سال، ما به صورت دوره ای بررسی ابزارهای مدیریت پایگاه داده را منتشر می کنیم که در آنها توجه زیادی به محصولات Embarcadero شده است.

ComputerPress:دیوید، بخش شما اکنون سه سال است که بخشی از Embarcadero است. دو سال پیش، شما سرشار از این واقعیت بودید که این شرکت از نظر هدف و روحیه بخشی از یک شرکت نزدیک به شما شده است. آیا در این مدت چیزی تغییر کرده است؟ آیا شما و همکارانتان همین شور و شوق را دارید؟

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

انتشار RAD Studio XE 2 که قصد داریم آن را در مسکو به نمایش بگذاریم، بزرگترین نسخه از این محصول با قابلیت های عظیم و تعداد زیادی پلتفرم پشتیبانی شده از زمان اولین نسخه دلفی است که برای ویندوز 16 بیتی و نوآوری سابق ایجاد شده است. محصولی که رویکرد مؤلفه و کامپایل را به کد ماشین متصل می کند. در حال حاضر ما از توسعه نه تنها برای ویندوز بلکه برای مکینتاش پشتیبانی می کنیم، نه اینکه به توسعه وب و ایجاد برنامه های کاربردی برای دستگاه های تلفن همراه اشاره کنیم و این برنامه ها برای پلتفرم های مختلف می توانند یک کد واحد داشته باشند.

پلتفرم توسعه جدید FireMonkey با همکاری Embarcadero و شرکت روسی KSDev مستقر در Ulan-Ude که اخیراً خریداری شده است، سازنده اجزای گرافیکی برداری، DirectX و OpenGL، فناوری‌های جلوه‌های گرافیکی و اجزای دلفی با استفاده از GPU با PixelShader 2.0 است. ما یک سال پیش شرکت KSDev (به ksdev.ru مراجعه کنید) را خریداری کردیم و شروع به کار با هم برای ایجاد یک ابزار توسعه چند پلتفرمی کردیم که شامل پلت فرمی برای توسعه برنامه های FireMonkey با اجزای دلفی و C ++ Buider برای ایجاد رابط کاربری برنامه، یکپارچه سازی است. با پایگاه داده، پردازش گرافیکی با استفاده از پردازنده گرافیکی و ادغام با سیستم عامل.

با استفاده از FireMonkey، می‌توانید برنامه‌ای ایجاد کنید که CPU و GPU را با هم اجرا کند، و سپس با استفاده از کامپایلرها و کتابخانه‌های زمان اجرا (Run-time Libraries، RTL) می‌توانید آن را برای Windows، Mac OS یا iOS کامپایل کنید. به جای یادگیری برنامه نویسی با کتابخانه های گرافیکی مختلف، یادگیری API ها از پلتفرم های مختلف با سیستم های مختصات مختلف و قابلیت های مختلف، توسعه دهندگان با استفاده از دلفی و C++Builder می توانند از رویکرد کامپوننت یکسانی استفاده کنند، فرم ها را به صورت بصری ویرایش کنند و با جابجایی کامپوننت به پایگاه داده ها متصل شوند. موش این یک روش اساسی جدید برای ایجاد برنامه هایی است که بر روی پلتفرم های مختلف اجرا می شوند و آینده است. اگر می خواهید پشتیبانی از سیستم عامل ها و پلتفرم های دیگر را به برنامه خود اضافه کنید، نیازی به طراحی مجدد و توسعه آن ندارید - فقط کافی است آن را دوباره کامپایل کنید.

ما کامپایلرهای جدیدی ایجاد می کنیم که کد بومی تولید می کنند. امروزه کامپایلرهای دلفی برای نسخه های 32 بیتی و 64 بیتی ویندوز، نسخه های 32 بیتی سیستم عامل مک 10 وجود دارد. و ما در حال کار بر روی کامپایلرهای نسل بعدی دلفی و C++ Builder هستیم که به شما امکان می دهد کارایی بالا ایجاد کنید. کد بومی هم برای اینها و هم برای سایر پلتفرم‌هایی مانند اندروید یا لینوکس و با استفاده از کامپایلرهای مختلف و کتابخانه‌های زمان اجرا، طراحی یکسان، اجزای یکسان، کدهای مشابه را حفظ کنید.

همانطور که می بینید، من دلایل کافی برای اشتیاق دارم. و توسعه دهندگانی که در سرتاسر جهان ملاقات می کنم می دانند که Embarcadero سرمایه گذاری زیادی روی دلفی و C++Builder و همچنین ابزارهای توسعه PHP انجام می دهد.

KP:در دو سال گذشته چه پیشرفتی در ادغام ابزارهای دو شرکت داشته اید؟ برنامه Embarcadero برای آینده در این زمینه چیست؟

DI.:در زمانی که بخش CodeGear بخشی از Embarcadero شد، این شرکت تیم های توسعه در تورنتو، مونتری و رومانی داشت، ما در Scotts Valley و در روسیه، در سنت پترزبورگ بودیم و هستیم. Embarcadero ابزارهای توسعه‌دهنده و مدیران پایگاه داده داشت، CodeGear ابزارهای توسعه برنامه‌ها را داشت، اما دومی از پایگاه‌های داده نیز استفاده می‌کرد. ادغام شرکت ها ترکیبی از تخصص، دانش در زمینه بانک های اطلاعاتی، بهینه سازی کد از جمله کد سرور است. این ادغام همچنین منجر به ایجاد یک محصول جدید به نام AppWave شد، یک فناوری ویژه برای تبدیل یک برنامه معمولی ویندوز به چیزی بسیار آسان برای استفاده (مانند برنامه های کاربردی برای آیفون یا دستگاه های دیگر). AppWave به شما این امکان را می دهد که برنامه ای را نصب نکنید، بلکه به سادگی آن را انتخاب کرده و از سرور ذخیره سازی برنامه (app) آماده شده اجرا کنید، در حالی که بدون ایجاد تغییرات در منطقه رجیستری و سیستم فایل آن، بر روی رایانه کاربر اجرا می شود. به هر حال، مرورگر برنامه AppWave در دلفی نوشته شده است. Embarcadero از Dephi برای توسعه خود و تخصص توسعه برنامه ما استفاده می کند.

برنامه آیفون (iOS) ایجاد شده توسط
با استفاده از پلتفرم FireMonkey

همچنین می توانید از ادغام ابزارهای توسعه ما و DB Optimizer برای بهینه سازی پرس و جوهای SQL هنگام ساخت برنامه ها استفاده کنید. با ارسال مستقیم کد SQL به DB Optimizer، می توانید آن را نمایه کنید، آن را آزمایش کنید و نسخه بهینه شده آن را به محیط توسعه بازگردانید. تخصص پایگاه داده Embarcadero همچنین فناوری DataSnap را بهبود بخشیده است. با تشکر از توسعه دهندگان تورنتو، ما دانش زیادی در مورد معماری سیستم ها و پایگاه های داده چند لایه به دست آورده ایم. ما اکنون تخصص مشترکی در کد سرور و رویه های ذخیره شده در هر دو شرکت داریم. ما ابزارهایی مانند RapidSQL و DB Change Manager و محیط‌های توسعه‌ای داریم که ایجاد کدهای سمت سرور را آسان می‌کنند، مانند فناوری‌های Code Insight و Code Completion که امکان ایجاد فناوری‌های SQL Insight و SQL Completion را فراهم کرده‌اند. رویکرد مشترک ما برای ایجاد کد مشتری و سرور، فلسفه مشترک ما، به ما امکان می دهد ویژگی های مشترکی را بین ابزارهای مدیریت پایگاه داده و ابزارهای توسعه برنامه به اشتراک بگذاریم.

کریل رانف:من می خواهم یک چیز مهم اضافه کنم. از نقطه نظر تجاری، نحوه ارائه ابزارهای خود بسیار مهم است. به عنوان مثال، نسخه جدید RAD Studio XE 2 Ultimate شامل مجموعه کامل ابزارهای DB Power Studio است. این مجموعه ابزارهای بسیار قدرتمندی است، از جمله محیط نگارش پرس و جو RapidSQL، ابزار مدیریت تغییر DB Change Manager و ابزار بهینه سازی پرس و جو DB Optimizer، که به شما امکان می دهد بخش مهمی از فرآیند توسعه و استقرار، مدیریت تغییرات را انجام دهید. مدل داده، پایگاه داده، کد و غیره این ترکیب بسیار خوب و درستی از فناوری ها است.

DI.:اما، در صورت نیاز، توسعه‌دهندگان می‌توانند از Subversion برای مدیریت نسخه‌های کد منبع و مدیریت تغییر DB برای مدیریت نسخه‌های ابرداده استفاده کنند. می توانید از پروفایل کد و DB Optimizer برای بهینه سازی کد سرور، RapidSQL برای ساخت و اشکال زدایی کد سرور و محیط های توسعه ما برای ساخت و اشکال زدایی برنامه ها استفاده کنید. این ترکیب از فناوری‌ها در RAD Studio XE Ultimate Edition شباهت‌های بین مدل‌های توسعه پایگاه داده و برنامه را نشان می‌دهد. اکثر توسعه دهندگانی که با دلفی و C++Builder برنامه های تجاری می سازند با پایگاه های داده کار می کنند و به این ابزارها نیاز دارند و RAD Studio XE Ultimate Edition ترکیبی عالی برای این توسعه دهندگان است.

KP:کاربر مدرن دیگر به تنهایی کاربر پلتفرم ویندوز نیست. ما از دستگاه های تلفن همراه، آیفون، آی پد، دستگاه های مبتنی بر پلت فرم اندروید استفاده می کنیم. این بدان معنی است که توسعه دهندگان باید بدون افزایش قابل توجهی در سرمایه گذاری در آموزش، پلتفرم های مختلف را هدف قرار دهند - یعنی ابزارهای جهانی مورد نیاز است. بدیهی است که انتظار ظهور ابزارهای جهانی از سوی سازندگان پلتفرم غیرواقعی است و در این مورد تنها می توانیم به سازندگان ابزار مستقل تکیه کنیم. کجا می توانیم به Embarcadero تکیه کنیم؟

DI.:ما هنوز کارهای زیادی در زمینه پشتیبانی از پلتفرم داریم. امروز ما در حال معرفی پشتیبانی از پلتفرم iOS برای آیفون و آیپد و به دنبال آن پشتیبانی از گوشی های هوشمند اندروید، ویندوز 7 و بلک بری هستیم. در RAD Studio XE 2، ما با ساخت پلتفرم FireMonkey برای iOS شروع کردیم و بعداً FireMonkey را به پلتفرم های دیگر پورت خواهیم کرد.

در عین حال، تعداد زیادی سیستم عامل وجود دارد که از صفحه نمایش های لمسی (صفحه نمایش لمسی)، برای تلفن، تبلت و دستگاه، رایانه های رومیزی پشتیبانی می کنند و ما به افزودن پشتیبانی از آنها ادامه خواهیم داد. علاوه بر این، سیستم‌های کنترل صوتی، سیستم‌های کنترل حرکت، سیستم‌های بیومتریک، شتاب‌سنج‌ها وجود دارد، بنابراین باید به گسترش FireMonkey ادامه دهیم تا همه توسعه‌دهندگان بتوانند از پلتفرم‌های جدید استفاده کنند. به عنوان مثال، دستگاه مایکروسافت کینکت برای Xbox 360 طراحی شده است و اکنون یک SDK (کیت توسعه نرم افزار) مربوط به ویندوز وجود دارد. و ما قبلاً نمونه هایی داریم که در آنها از حرکت برای کنترل یک برنامه به همان روشی که معمولاً از ماوس یا صفحه کلید استفاده می کنیم استفاده می کنیم.

هنگامی که برنامه هایی با تعداد زیادی گرافیک پیچیده ایجاد می کنید، دنیای کاملی از رابط های کاربری جدید ایجاد می کنید. اگر با سیستم عامل ویندوز سر و کار داریم، API ویندوز آن را در کتابخانه VCL (Visual Component Library - یک کتابخانه اجزای بصری که بخشی جدایی ناپذیر از ابزارهای توسعه دلفی و C ++ Builder است) کپسوله می کنیم. - توجه داشته باشید. ویرایش، که به هر حال، می تواند بیشتر اعمال شود. و در FireMonkey، API سیستم عامل را کپسوله می کنیم. اما امروزه ما فرم ها و گرافیک ها را بسیار بیشتر دستکاری می کنیم. همچنین می توانید ویژگی های فضای فیزیکی را برای انیمیشن و جلوه های ویژه اضافه کنید. علاوه بر این، تعداد زیادی ویژگی اضافی دیگر برای ایجاد رابط کاربری وجود دارد که قرار است در چند سال آینده برای پلتفرم‌های مختلف، دستگاه‌های موبایل و تبلت اجرا کنیم.

مایکروسافت اخیراً جزئیات مربوط به ویندوز 8 را منتشر کرده است که قرار است یک سال دیگر عرضه شود. ما از این نوآوری ها در کتابخانه VCL و در پلت فرم FireMonkey پشتیبانی خواهیم کرد. اما دلفی یک ابزار توسعه است که نه تنها برای ویندوز، بلکه برای مکینتاش، آیفون و آیپد نیز طراحی شده است. ما همچنین محصولات PHP خود را توسعه می‌دهیم، از jQuery Mobile پشتیبانی می‌کنیم، از iOS API برای توسعه برنامه‌های سرویس گیرنده تلفن همراه استفاده می‌کنیم، و برنامه‌های PHP سمت سرور را با استفاده از جادوگران و ابزارهایی برای تولید جاوا اسکریپت، HTML، و برگه‌های سبک آبشاری سمت کلاینت ایجاد می‌کنیم. ما می‌توانیم برنامه‌های PHP و برنامه‌های کلاینت اصلی iPhone iOS را بسته بندی کنیم، در حالی که مشتری با سرور PHP صحبت می‌کند. و این، به نوبه خود، با سرور پایگاه داده و با خدمات وب - با همه چیزهایی که برای تجارت مورد نیاز است، ارتباط برقرار می کند.

محیط توسعه RadPHP XE2. یک وب اپلیکیشن موبایل ایجاد کنید
با استفاده از اجزای jQuery Mobile برای iPhone 3G

به عبارت دیگر، قصد داریم قابلیت های FireMonkey و VCL از جمله پشتیبانی از پلتفرم های موبایل را گسترش دهیم.

KP:آیا می توانید در مورد پلتفرم FireMonkey بیشتر توضیح دهید؟

DI.:همانطور که قبلاً اشاره کردم، کتابخانه VCL ایجاد شده برای ویندوز به توسعه و بهبود ادامه خواهد داد. اما امروزه، اگر می خواهید واقعاً برنامه های تجاری توسعه دهید، باید آنها را برای پلتفرم های مختلف ایجاد کنید. این همان چیزی است که پلتفرم FireMonkey برای آن طراحی شده است. از ایجاد رابط های کاربری با وضوح بالا، گرافیک سه بعدی با کارایی بالا، نرخ فریم بالا پشتیبانی می کند و مهمتر از همه، از GPU برای انجام این کار استفاده می کند.

شما می توانید از این ویژگی ها هنگام ایجاد برنامه های علمی، مهندسی و تجاری استفاده کنید. چنین برنامه‌هایی می‌توانند با استفاده از فناوری dbExpress به پایگاه‌های داده متصل شوند، همچنان از اجزای غیر بصری آشنا برای توسعه‌دهندگان مانند ClientDataSet یا DataSource استفاده می‌کنند، از فناوری DataSnap استفاده می‌کنند، به هر پایگاه داده، سرورهای SOAP و REST متصل می‌شوند. می‌توانید کنترل‌های جذاب، دکمه‌های جعبه‌دار، جداول فانتزی و سایر عناصر رابط را به صورت دو بعدی و سه بعدی ایجاد کنید. می توانید یک مدل سه بعدی آماده را در برنامه بارگذاری کنید و آن را با یک شکل دو بعدی ترکیب کنید که در آن می توان آن را چرخاند و از زوایای مختلف مشاهده کرد. می توانید یک مکعب داده یا یک نمودار تجاری سه بعدی ایجاد کنید و با استفاده از ماوس، صفحه کلید یا حتی یک دستگاه کینکت آن را بچرخانید یا می توانید به داخل مکعب بروید و از داخل به سطوح مختلف آن نگاه کنید. و همه اینها را می توان با یک پردازنده گرافیکی پرسرعت انجام داد. سپس همان برنامه را می توان برای پلتفرم دیگری مانند سیستم عامل مک کامپایل کرد.

برنامه حاوی یک مکعب چرخان با داده،
روی لبه های آن قرار می گیرد

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

در ویندوز، می توانید از کتابخانه های Direct2D برای گرافیک های دو بعدی با وضوح بالا و از Direct3D برای گرافیک های سه بعدی استفاده کنید. سیستم عامل مک از کتابخانه های کوارتز و OpenGL برای همین منظور استفاده می کند. برای iOS، از کتابخانه های Quartz و OpenGL ES استفاده می شود. اما همه اینها از توسعه دهنده پنهان است - او از پلتفرم FireMonkey، سیستم مختصات آن و رابط برنامه نویسی برنامه استفاده می کند، بدون اینکه به این کتابخانه ها فکر کند، و می تواند همان برنامه را برای پلتفرم های مختلف کامپایل کند.

بیایید به یاد بیاوریم که VCL چیست. VCL یک کامپوننت "Wrapper" در اطراف API ویندوز است. ما با منابع، منوها، کادرهای محاوره ای، رنگ ها، سبک ها، پیام های ویندوز سروکار داریم. FireMonkey بر خلاف VCL، یک بسته چند پلتفرمی است، همان رویدادها و مدل‌های مؤلفه را حفظ می‌کند، و به شما امکان می‌دهد به رویدادها فکر کنید (به عنوان مثال، رویدادهای OnClick، OnHasFocus، onMouseDown و onKeyDown)، اما رویدادهای Macintosh یا iPhone را مدیریت کنید.

فریم ورک FireMonkey همچنین دارای یک سیستم کامل برای متحرک سازی عناصر رابط کاربری است. مطمئناً این یک سیستم پویانمایی جامع به سبک پیکسار نیست، اما به شما امکان می دهد افکت هایی مانند متحرک سازی بیت مپ، برجسته کردن تمرکز عنصر رابط کاربری و کار با گرافیک های برداری را اعمال کنید. بیش از 50 جلوه بصری در دسترس توسعه دهنده است: تار کردن، تبدیل تصویر به سیاه و سفید، حل شدن، انتقال، انعکاس، ایجاد سایه - همه انواع جلوه های موجود در GPU های مدرن که اکنون تقریباً در هر رایانه ای وجود دارد. برنامه ای که با استفاده از پلتفرم FireMonkey ساخته شده است، دستوراتی را به GPU ارسال می کند، که تمام کارهای نمایش گرافیک و ایجاد رابط کاربری را انجام می دهد. در عین حال، پردازنده مرکزی برای محاسبات و دسترسی به سیستم عامل رایگان است. توسعه دهنده فقط باید اجزا را به درستی قرار دهد.

اساسی ترین چیز در مورد پلتفرم FireMonkey نحوه ایجاد رابط کاربری است. امکاناتی برای قرار دادن گرافیک بیت مپ روی عناصر رابط مانند منوها، دکمه ها و نوارهای اسکرول وجود دارد. در FireMonkey از گرافیک برداری GPU برای این منظور استفاده می کنیم. از نقطه نظر برنامه نویسی، همه اینها کنترل ها یکسان هستند، اما پردازنده گرافیکی تمام کار نمایش آنها را انجام می دهد. می‌توانیم استایل‌ها را روی کنترل‌ها اعمال کنیم، برنامه‌ای را شبیه برنامه‌ای برای Mac OS یا Windows کنیم، سبک خودمان را ایجاد کنیم، استایل‌هایمان را روی عناصر رابط اعمال کنیم (مثلاً با تغییر سبک آن در ویرایشگر فرم، یک دکمه مستطیلی یا گرد بسازیم) - برای این محیط توسعه یک ویرایشگر سبک دارد. شما می توانید سبک خود را ایجاد کنید یا می توانید سبک برنامه ای را که قبلاً تمام شده است تغییر دهید.

FireMonkey Platform - ابزارهای توسعه
و پلتفرم های پشتیبانی شده

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

سیستم رندر FireMonkey کاملاً منعطف است - می‌تواند از کتابخانه‌های Direct2D، Direct3D و OpenGL با ارسال دستورات به GPU استفاده کند. برای دستیابی به همین امر در VCL، لازم بود یک بافر خارج از صفحه جداگانه تولید شود، با فراخوانی توابع مناسب کتابخانه های گرافیکی، تصویری در آن ایجاد شود و سپس آن را در فرم نمایش دهد.

نمونه هایی از جلوه های گرافیکی پشتیبانی شده توسط FireMonkey

اگر پردازنده گرافیکی ندارید، همچنان می توانید اشکال دو بعدی یا سه بعدی را اعمال کنید و از کنترل های FireMonkey استفاده کنید. در این صورت پلتفرم FireMonkey از کتابخانه های +GDI یا سایر کتابخانه های مشابه استفاده می کند و همان افکت ها و انیمیشن یا دستکاری اشیاء سه بعدی را انجام می دهد.

یکی دیگر از ویژگی های FireMonkey سیستم جدید اتصال عناصر رابط به داده ها است که باز و انعطاف پذیر است. دو نوع عنصر واسط در VCL وجود دارد: محدود به داده و غیر محدود به داده (به عنوان مثال، TDBEdit و TEdit). در FireMonkey، هر کنترلی را می توان با داده ها، از هر نوع، مرتبط کرد. این می تواند فقط یک عبارت، یک فیلد از مجموعه داده، داده های اشیاء ایجاد شده توسط توسعه دهنده یا نتایج فراخوانی روش باشد.

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

نمونه هایی از تغییر سبک های برنامه

KP:در حال حاضر چه فرمت های مدل سه بعدی پشتیبانی می شود؟

DI.:در این نسخه، ما از بارگیری مدل‌های اتوکد، کولادا (یک ابزار مدل‌سازی سه بعدی منبع باز) پشتیبانی می‌کنیم. توجه داشته باشید. ویرایش.)، مایا، یک فرمت OBJ که توسط بسیاری از فروشندگان گرافیک سه بعدی پشتیبانی می شود.

KP:چه فرمت های دیگری برای اضافه شدن برنامه ریزی شده است؟

DI.:ما قصد داریم 3DS (3D Studio MAX)، SVG (معمولا این فرمت برای گرافیک های برداری 2 بعدی استفاده می شود، اما گاهی اوقات برای 3D)، Google SketchUp را اضافه کنیم. ما ممکن است از فرمت های دیگر نیز پشتیبانی کنیم.

KP:آیا استفاده از مدل های سه بعدی در برنامه های ساخته شده با FireMonkey نیاز به مجوز ابزار مدل سازی سه بعدی مناسب دارد؟

DI.:نه، اینطور نیست. تنها کاری که ما انجام می دهیم خواندن فایل مدل است. ما مدل را وارد می کنیم اما آن را صادر نمی کنیم (البته شما می توانید برنامه ای بنویسید که مدل را در قالب خود ذخیره کند). ما ادعا نمی کنیم که سازنده ابزارهای مدل سازی سه بعدی هستیم - برای این کار می توانید از AutoCAD، 3D Studio Max، Maya یا هر ابزار مدل سازی سه بعدی دیگری استفاده کنید و مدل های ایجاد شده را به برنامه های ما وارد کنید.

KP:برنامه هایی که با FireMonkey بر روی پلتفرم های سخت افزاری مدرن ساخته شده اند چقدر کارایی دارند؟

DI.:عملکرد بسیار بالا است. به عنوان مثال، یک شکل سه بعدی با سه کره و سه نور را می توان با سرعت 100 فریم در ثانیه در مک بوک پرو ارائه کرد. و می تواند به 600 برسد - بستگی به این دارد که دقیقاً چه کاری انجام می دهیم. باز هم، همه چیز به قدرت پردازنده گرافیکی بستگی دارد.

KP:آیا این بدان معناست که با کمک FireMonkey می توانید بازی هایی را ایجاد کنید که نیازهای مدرن را برآورده کنند؟

DI.:ما ابزارهای توسعه خود را به عنوان ابزاری برای بازی ها قرار نمی دهیم. با این حال، با استفاده از عملکرد بالای پردازنده‌های گرافیکی مدرن، می‌توانید بازی‌هایی را با FireMonkey نیز ایجاد کنید - از این گذشته، آنها با استفاده از Direct3D یا OpenGL ایجاد می‌شوند.

KP:اکنون در زمینه پشتیبانی از تشخیص ژست و سایر موارد جدید چه کاری انجام می دهید؟ آیا چنین پشتیبانی در دسترس است؟

DI.:ما هنوز پشتیبانی ژست‌های حرکتی در این نسخه نداریم. کنترل حرکت در نسخه بعدی FireMonkey اضافه خواهد شد، اما در حال حاضر، می توانید از پشتیبانی ژست های موجود در سیستم عامل استفاده کنید.

میخائیل فیلیپنکو، مدیر Fast Reports, Inc.

K.R.:قبلاً گفتیم که فناوری FireMonkey ریشه روسی دارد - پایه های آن در کشور ما ایجاد شد و سپس خود فناوری و توسعه دهندگان آن در Embarcadero ادغام شدند. به طور کلی، دیدن رشد کامپوننت روسی در استودیو RAD و دلفی خوشحال کننده است. این فعالیت مرکز توسعه ما در سن پترزبورگ و مشارکت توسعه دهندگان مستقل روسی است. به عنوان مثال Rad Studio XE2 شامل تولید کننده گزارش FastReport است که در سراسر جهان شناخته شده و در کشور ما بسیار محبوب است. او اهل روستوف-آن-دون است.

KP:من می خواهم در مورد کامپایلرها صحبت کنم. برای ایجاد اپلیکیشن های iOS از چه کامپایلری استفاده می شود؟

DI.:ما کامپایلر دلفی خود را برای iPhone یا iPad نداریم - ما هنوز کامپایلرهایی برای پردازنده های ARM مورد استفاده در این دستگاه ها ایجاد نکرده ایم. برای iOS، ما به طور موقت از کامپایلر رایگان پاسکال و کتابخانه زمان اجرا استفاده می کنیم. اما ما در حال کار بر روی نسل بعدی کامپایلرها، از جمله کامپایلرهای پردازنده های ARM هستیم. اما کامپایلرهایی برای ویندوز و سیستم عامل مک وجود دارد، زیرا هر دو پلتفرم سخت افزاری مبتنی بر پردازنده های اینتل هستند.

KP:و در زمینه توسعه کامپایلر در دو سال اخیر چه اقداماتی انجام شده است؟

DI.:ما کامپایلرهای دلفی 32 و 64 بیتی برای ویندوز و سیستم عامل مک داریم. و ما روی نسل جدیدی از کامپایلرهای دلفی و سی پلاس پلاس کار می کنیم. کار بر روی آنها هنوز ادامه دارد، اما پس از تکمیل، ما کامپایلرهای دلفی را برای پردازنده های ARM، پلتفرم های اندروید، لینوکس و هر چیز دیگری خواهیم داشت. و ما کامپایلرهای 64 بیتی C++ را برای ویندوز و سایر پلتفرم‌ها خواهیم داشت که با آخرین استاندارد زبان C++ که به تازگی توسط ISO پذیرفته شده است، سازگار است.

KP:امروز در مورد پشتیبانی رایانش ابری در ابزارهای توسعه Embarcadero چه می گذرد؟

DI.:با RAD Studio XE 2، ما از انتقال برنامه ها به Microsoft Azure یا Amazon EC2 cloud با استفاده از دستیار پلتفرم پشتیبانی می کنیم. و ما اجزای سرور را برای Cloud Storage برای Azure و Amazon S3 برای ذخیره جداول، داده‌های باینری، صف‌های پیام داریم. در نسخه قبلی RAD Studio XE، ما از استقرار برنامه‌ها در Amazon EC2 نیز پشتیبانی می‌کردیم، اما هیچ پشتیبانی ذخیره‌سازی وجود نداشت.

پشتیبانی از رایانش ابری در RAD Studio XE 2

KP:دو سال پیش در مورد راه حل جدید All-Access صحبت کردید. چقدر تقاضا داشت؟ مزایای آن برای یکپارچه سازان و توسعه دهندگان سیستم چیست؟

DI.:راه حل All-Access و ابزار ابری AppWave به طور گسترده در سراسر جهان استفاده می شود. آنها به گونه ای طراحی شده اند که استفاده از برنامه های شرکت ما و برنامه های شخص ثالث را آسان تر کنند. در واقع، این یک راه حل برای مدیریت مجوزها و برنامه ها است و برای شرکت های بزرگ راحت است. شرکت‌های کوچک‌تر که تیم مدیریت برنامه‌های کاربردی اختصاصی ندارند، می‌توانند برنامه را در یک مخزن قرار دهند، نام‌های کاربری را از پایگاه داده انتخاب کنند و آن برنامه‌ها را برای استفاده در دسترس قرار دهند، بدون اینکه نیازی به یادآوری اینکه کلید مجوز کجاست و چند مجوز در دسترس است. All-Access و مرورگر AppWave برای مدیریت نسخه و کنترل دسترسی طراحی شده اند.

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

کار بسته‌بندی ابزارهای توسعه در کیت‌های کاربر مؤثر هنوز ادامه دارد. ما All-Access داریم - یک مجموعه فوق العاده که همه محصولات Embarcadero را ترکیب می کند. اگر مشتری نسخه All-Access Platinum را خریداری کند، تمام ابزارهایی را که در Embarcadero هستند دریافت می کند. اما گاهی اوقات این مجموعه اضافه می شود، به عنوان مثال، ما دو مجموعه دیگر را برای متخصصان پایگاه داده ساختیم - DB Power Studio Developer Edition و DB Power Studio DBA Edition. تفاوت بین آنها در این است که ما RapidSQL را برای توسعه دهنده ارائه می دهیم - ابزاری برای توسعه کد سرور، و برای مدیر DBArtizan داخلی وجود دارد - ابزار مدیریت پایگاه داده، محصولی گسترده تر از RapidSQL. برای حرفه‌ای‌ها، مجموعه‌های All-Access زیر را داریم: مجموعه تمام محصولات، DB Power Studio برای توسعه‌دهندگان، DB Power Studio برای مدیران، ER Studio Enterprise Edition برای معماران و هر کسی که در مدل‌سازی فعالیت می‌کند. ترکیباتی برای توسعه برنامه و برای مدیران وجود دارد. دلفی یک ابزار توسعه دهنده است و افزودن ابزارهای توسعه SQL و ابزارهای بهینه سازی به آن بسیار منطقی است. در نهایت، DB Change Manager یک ابزار بسیار منطقی برای مدیریت پیچیدگی تغییراتی است که در طول چرخه عمر پایگاه داده ها رخ می دهد.

بنابراین، All-Access رئیس یک خانواده بزرگ از مجموعه های مختلف محصولات است.

KP:اگر راز نیست، چه کسی در روسیه از All-Access استفاده می کند؟

K.R.:ما مشتریانی داریم که All-Access را بر اساس دلفی خریده اند. بسیاری از آنها با SQL Server و Oracle در حال ساختن سیستم های پیچیده کلاینت-سرور هستند و بلافاصله از مجموعه ابزار پایگاه داده متقابل پلتفرم ما خوششان آمد. ما یک شرکت مشتری داریم که از نسخه اول با دلفی کار می کند و یک سال پیش از دلفی به All-Access نقل مکان کرد. دو ابزاری که برای تمامی توسعه دهندگان این شرکت تضمین شده است دلفی و دی بی آرتیسان هستند. و مشتریانی هستند که از سمت پایگاه داده به All-Access آمده اند. کار اصلی آنها مدیریت پایگاه های داده است، اما گاهی اوقات برنامه های کاربردی را نیز توسعه می دهند. مشتریانی که از All-Access استفاده می کنند شامل شرکت های رسانه ای، ماشین سازان و سایر صنایع می شوند.

به طور جداگانه، من می خواهم به شرکت های کوچک بپردازم. اغلب در تیم های کوچک، توسعه دهنده همه کارها را انجام می دهد و چنین شرکتی گاهی بسته های غذایی بزرگ All-Access را برای یک یا دو توسعه دهنده خریداری می کند. در تیم‌های بزرگ تشویق نمی‌شود که توسعه‌دهنده نقش مدیر پایگاه داده را نیز ایفا کند، بنابراین بسته‌های غذایی کوچک معمولاً در آنجا محبوب هستند و در شرکت‌های کوچک این ترکیب وظایف کاملاً قابل قبول است.

معمار دلفی محصولی است که به شدت به بازار عرضه می شود که شامل ابزارهای مدل سازی و برنامه نویسی می شود. تعداد نسخه های فروخته شده، با این حال، کمتر از نسخه های دلفی اینترپرایز است، اما در عین حال زیاد است. توجه دارم که در سال 2010 ما بهترین کشور از نظر فروش بودیم، علیرغم اینکه همه کشورها از بحران جان سالم به در بردند. این رشد نه به دلیل عوامل اقتصادی بلکه به دلیل این واقعیت بود که نسخه RAD Studio XE که در پایان سال 2009 منتشر شد، تقاضای زیادی داشت. و در حالی که ما انتظار رشد بیشتر در فروش را داریم.

ما گام معقول دیگری برداشتیم که در روسیه بسیار مورد تقاضا است. درجه قانونی شدن نسخه های مختلف محصولات ما متفاوت است: هر چه نسخه بالاتر باشد، قانونی تر است، زیرا قبلاً نرم افزار به طور فعال خریداری نمی شد. با شروع RAD Studio XE، مجوز نسخه های 2010، 2009، 2007 و حتی دلفی 7، محصولی پرکاربرد را پوشش می دهد.

امروزه توسعه‌دهندگان با این واقعیت روبرو هستند که هم پروژه‌های جدید و هم پروژه‌هایی در حالت پشتیبانی دارند. تعداد زیادی از پروژه ها از نسخه های اولیه دلفی به نسخه 7 منتقل شده اند و در این نسخه باقی می مانند و به کار بر روی منابع نسبتاً کوچک ادامه می دهند. هیچ کس آنها را به نسخه های جدیدتر منتقل نمی کند، اما آنها زنده نگه داشته می شوند. و اکنون ما با پول کمی (کمتر از قیمت مجوز دلفی 7) اجازه می دهیم RAD Studio XE و Delphi 7 را دریافت کنیم - یعنی توسعه دهنده را هم برای اجرای پروژه های جدید و هم برای پروژه های پشتیبانی قانونی می کنیم.

KP:وضعیت فعلی جامعه Embarcadero را چگونه ارزیابی می کنید؟

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

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

KP:اگر شرکتی دستگاه جدیدی ایجاد کند و بخواهد از FireMonkey پشتیبانی کند، آیا این امکان وجود دارد؟

DI.:با کامپایلرهای نسل جدید که دارای یک فرانت اند مستقل از پلتفرم و یک بک اند وابسته به پلتفرم خواهند بود، این امر کاملا امکان پذیر خواهد بود. در این بین برای هر سیستم عامل از ابتدا یک کامپایلر و کتابخانه زمان اجرا ایجاد می کنیم.

هر دستگاه جدید مدرن معمولا دارای یک رابط کاربری گرافیکی (بسیاری از آنها دارای پردازنده دو هسته ای و GPU هستند) و SDK های استاندارد برای توسعه دهندگان. همه اینها ایجاد پشتیبانی از دستگاه را در FireMonkey ساده می کند. اگر دستگاه جدید فقط کتابخانه هایی برای گرافیک های دو بعدی مانند Quartz داشته باشد، ما می توانیم از چنین دستگاهی در FireMonkey پشتیبانی کنیم، اما این تقریباً چندین ماه طول می کشد. با این حال، خیلی چیزها به پلتفرم بستگی دارد: همه پلتفرم ها از همه ویژگی ها پشتیبانی نمی کنند، به عنوان مثال، iOS منوها و کادرهای محاوره ای ندارد و شما نمی توانید اجزای مربوطه را روی فرم های چنین برنامه هایی قرار دهید.

KP:آیا چیزی در سیاست کار با شرکا تغییر کرده است؟ برای افزایش سهم کاربران از محصولات شما چه اقداماتی انجام می شود؟ در روسیه چه می شود؟

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

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

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

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

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

FireMonkey فناوری اصلی "دلفی ​​جدید" است. لطفاً در مورد اهداف، قابلیت ها و جنبه های فنی این کتابخانه کاملاً جدید به ما بگویید. پس از مدتی، با نگاهی به گذشته، امتناع شما از توسعه بیشتر VCL فوق العاده محبوب چقدر سخت و موجه بود؟

این به عنوان مسیر اصلی توسعه فناوری دلفی برای دستیابی به یک هدف خاص انتخاب شد - توسعه چند پلتفرمی از یک محیط، بر اساس یک پایه کد منبع واحد و بدون نیاز به بازآموزی اساسی توسعه دهندگان. در چارچوب VCL در حال حاضر کلاسیک و فوق العاده محبوب، این غیرممکن بود، ارتباط آن با WinAPI بسیار نزدیک بود، شاید بتوان گفت، "در سطح ژنتیکی".

اجزای VCL یک لایه "انتزاعی" بین سطح عملکردی از نظر رابط و مکانیسم های نقشه برداری آنها نداشتند. سطح عملکردی- چگونه به عنوان یک کنترل رفتار می کند، به چه رویدادهایی واکنش نشان می دهد، چه نوع تعامل با کاربر را فراهم می کند. نمایش دادن- فراخوانی متدهای رندر پلت فرم گرا به عنوان نوعی تصویر که توسط اشیاء شطرنجی و بردارهای اولیه تشکیل شده است. FireMonkey در ابتدا اصل تقسیم دقیق کنترل را به دو بخش اجرا کرد: "رفتاری" و "بصری".


وسوولود لئونوف، Embarcadero Technologies

اولین مورد به طور کلی نه حتی اصول اولیه VCL، بلکه ماهیت برنامه نویسی شی گرا را تکرار می کند. یک جزء یک کلاس است، کلاس های مؤلفه سلسله مراتبی را تشکیل می دهند که در آن خانواده ها و ماژول ها قابل تشخیص هستند. کلاس یک جزء ارتباط چندانی با نحوه رندر شدن آن ندارد.

"تصویر" بصری به صورت پویا شکل می گیرد، در کلاس جزء کدگذاری نشده است. یک تصویر یا "سبک" در FireMonkey هنگام شروع برنامه در یک مؤلفه بارگذاری می شود. ما نوعی چارچوب کاربردی برای کامپوننت داریم و "پوست" یا "پوشش" را می توان تغییر داد، اما چرا؟ به همین دلیل است که برنامه های FireMonkey در هر پلتفرمی معتبر به نظر می رسند - ویندوز 7، ویندوز 8، سیستم عامل مک، iOS و در آینده نزدیک، اندروید. ساختار کلاس سنتی یکپارچه VCL نمی تواند این را فراهم کند.

در اینجا رویکرد تکنولوژیک نقش ویژه ای ایفا می کند. در اصل، می‌توانید کتابخانه VCL را بگیرید و WinAPI را با همه تماس‌های پلتفرم احتمالی دیگر «چیز» کنید. در زیر مجموعه بسیار محدودی از کامپوننت‌ها، هنوز هم می‌توان این کار را انجام داد، اما VCL شامل صدها مؤلفه است، بنابراین این رویکرد به سادگی می‌تواند VCL را «کشته» کند. تصمیم گرفته شد که VCL را لمس نکنیم و ویژگی های جدیدی را در پلتفرم جدید - FireMonkey توسعه دهیم. این فناوری حتی دارای ظرافت فنی خاصی است - در زمان مونتاژ یک پروژه برای یک پلت فرم خاص، IDE دلفی کامپایلر لازم را به هم متصل می کند و اجزای رابط یک سبک پلت فرم را دریافت می کنند.

برای کاربر، این یک کلیک ماوس و همان کد منبع است، برای دلفی، سالها کار سخت توسعه دهندگان برای ایجاد چنین کتابخانه چند پلتفرمی است.

وقتی مشخص شد که FireMonkey به عنوان یک پلتفرم جدید مجزا معرفی می‌شود، باید استراتژی مناسبی برای همزیستی انتخاب می‌شد: Embarcadero به هیچ وجه نمی‌خواست بر کاربران VCL تأثیر منفی بگذارد. بنابراین، ما طرح زیر را انتخاب کرده‌ایم: VCL از نظر ایدئولوژیکی و معماری پایدار می‌ماند تا بیشترین سازگاری ممکن را تضمین کند، در حالی که مهاجرت پروژه‌ها به نسخه‌های مدرن را تسهیل می‌کند. توسعه FireMonkey یک مسیر طبیعی و موازی را بدون نگاه کردن به VCL دنبال خواهد کرد.

نقطه ضعف این راه حل، مهاجرت نسبتا مشکل ساز از VCL به FireMonkey در یک پروژه است. اما از سوی دیگر، برای یک پروژه جدید، یک توسعه‌دهنده می‌تواند FireMonkey را انتخاب کند تا از ماهیت چند پلتفرمی برنامه منتج شده خود اطمینان حاصل کند. با عرضه XE4 با پشتیبانی از iOS، می توان از مزیت رقابتی قوی دلفی برای توسعه موبایل در محیط شرکت صحبت کرد که پس از اجرای پشتیبانی برنامه ریزی شده برای اندروید، افزایش خواهد یافت.

بنابراین، به این ترتیب، هیچ "امتناع" صریحی از توسعه VCL وجود ندارد. در نسخه های جدید، قسمت VCL دلفی نیز در حال توسعه است. این شامل پشتیبانی از 64 بیت، و معرفی یک ظاهر طراحی برای اجزای بصری، و اجرای مکانیزمی برای پیوندهای پویا انعطاف پذیر یا "binding"، و گنجاندن کتابخانه FireDAC برای کار با پایگاه های داده در پروژه های VCL است. فقط این است که در پس زمینه یک جهش کیفی عظیم به دلیل FireMonkey، پیشرفت در VCL تا حدودی آشکار به نظر نمی رسد. اما به هر حال، VCL بخشی جدایی ناپذیر از دلفی است و برای سال های آینده نیز به همین شکل باقی خواهد ماند. اگرچه تکامل پلتفرم ها و وضعیت فعلی در زمینه سیستم عامل برای سیستم های دسکتاپ و دستگاه های تلفن همراه به گونه ای است که آینده به وضوح با FireMonkey است.

ما قبلاً در مصاحبه درباره پشتیبانی iOS صحبت کرده‌ایم، اجازه دهید به خوانندگان خود در مورد آخرین پشتیبانی RAD Studio XE4 برای سایر فناوری‌های جدید، مانند Windows 8 و WinRT، سیستم‌های 64 بیتی، MacOS و غیره بگوییم. آیا می توانید فهرست کنید چه چیز دیگری می توانید به یک برنامه نویس مدرن که توسط نوآوری ها خراب شده است ارائه دهید؟

به احتمال زیاد، برنامه نویس مدرن با نوآوری ها "فاسد" نشده است. برای پروژه های بزرگ، هر "نوآوری" اغلب به حجم عظیمی از کار تبدیل می شود.

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

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

یکی از این دستاوردهای «مشکل‌آمیز» انتشار ویندوز 8 بود. من شخصاً به عنوان یک کاربر رایانه شخصی و فقط یک متخصص فناوری اطلاعات مدرن، از ویندوز 8 خوشحالم. اما برای توسعه دهندگانی که دسته ای از رایانه های ویندوز 8 با مشخصات فنی برای توسعه تحت سیستم عامل جدید به عنوان بار ارسال شده اند، این به معنای مشکلات خاصی است.

ما سعی کردیم پشتیبانی از توسعه تحت رابط جدید این سیستم عامل را تا حد امکان راحت و بدون دردسر فراهم کنیم. بنابراین، سبک‌های خاصی هم برای VCL و هم برای FireMonkey معرفی شده‌اند و برنامه‌نویس می‌تواند رابط برنامه را بازسازی کند یا یک برنامه جدید ایجاد کند که از نظر ظاهری از "بومی" برای ویندوز 8 قابل تشخیص نباشد. البته نیاز به پشتیبانی «بومی» از ویندوز 8 از طریق WinRT وجود دارد. اما در اینجا اولویت بندی اهداف در شرایط مدرن تأثیر می گذارد. سیستم عامل مک، iOS، اندروید در آینده نزدیک هنوز فرصتی برای صحبت در مورد پشتیبانی کامل از WinRT در آینده نزدیک نمی دهد.

هدف استراتژیک Embarcadero البته چند پلتفرمی است. انتشار RAD Studio XE4 یک مورد کلیدی بود، در درجه اول به دلیل پشتیبانی از iOS. یک برنامه نویس فعال با استفاده از VCL می تواند در عرض چند ساعت شروع به توسعه برای iOS کند. حتی یک اپلیکیشن موبایل ساده را می توان فورا به یک پروژه قدرتمند تبدیل کرد که در زیرساخت های موجود کار می کند. فکر نکنید که این فقط یک کامپایلر جدید برای FireMonkey و یک سبک جدید برای مطابقت با رابط iOS است.

این شامل یک طراح بصری جدید، پشتیبانی داخلی برای فاکتورهای مختلف، کتابخانه های دسترسی به داده ها، از جمله FireDAC جدید، و فناوری LiveBindings برای اتصال انعطاف پذیر و پویا به داده های شرکتی است. همه این نوآوری ها به صورت همزمان ارائه می شوند - برای ویندوز، و برای سیستم عامل مک، و برای iOS. سیستم عامل Mac OS به سرعت در حال توسعه نیست، بنابراین هیچ مشکلی مانند انتقال از ویندوز 7 به ویندوز 8 وجود ندارد. اما نمایشگرهای رتینا ظاهر شدند و این نیاز به توجه ویژه داشت. اکنون هر برنامه MacOS ایجاد شده در Delphi XE4 به طور خودکار شامل دو سبک است - "normal" و "high-definition".

که همان برنامه می تواند رابط "بومی" با همان کیفیت را در هر رایانه رومیزی اپل داشته باشد.

Embarcadero نمی خواهد توسعه دهندگان را با نسخه های نوآورانه جدید خود "غافلگیر"، "متحیر" یا حتی "سرگرم" کند. در عوض، برعکس، حوزه فناوری اطلاعات در حال حاضر مملو از شگفتی های مختلف است: دستگاه های جدید، سیستم عامل های جدید، کاربران جدید، نیازهای جدید آنها، سناریوهای تعامل جدید. فناوری‌های توسعه نرم‌افزار جدید را به این اضافه کنید، و برنامه‌نویسان به سادگی زمان ایجاد سیستم‌های جدید و روی سیستم‌های موجود را نخواهند داشت - آنها فقط کاری را انجام می‌دهند که از یک محیط به محیط دیگر، از یک کتابخانه قدیمی به کتابخانه جدید، از یک زبان به دیگر مهاجرت کنند. یکی دیگر.

اما ما به رد هر چیز جدید اعتراف نمی کنیم. ما فقط می‌خواهیم از تداوم همه چیز اطمینان حاصل کنیم - کد، رابط، پروژه، حتی مهارت‌های حرفه‌ای که پلتفرم‌ها و دستگاه‌های جدید ظاهر می‌شوند. می‌توان گفت که ما با محافظه‌کاری ناسالم در رابطه با بسترهای جدید به قیمت محافظه‌کاری سالم در ابزارهای توسعه مبارزه می‌کنیم. از Embarcadero انتظار محصولات عجیب و غریب، زبان های برنامه نویسی غیر استاندارد و ابزارهای توسعه عجیب و غریب را نداشته باشید.

با ما همیشه توسعه بصری، زبان‌های کلاسیک، کدهای «بومی» را خواهید یافت و اجازه می‌دهید پلتفرم‌های هدف برنامه‌های کاربردی‌تان که به همان روش کلاسیک اثبات‌شده ایجاد شده‌اند، جدید باشند.

میمون آتش چیست؟


FireMonkey (FMX) چارچوبی برای توسعه بین پلتفرمی برای هر دو سیستم دسکتاپ (ویندوز، سیستم عامل مک + در آینده نزدیک، پشتیبانی از بخش سرور در لینوکس) و موبایل (iOS و Android) با استفاده از زبان دلفی/C++ است. .

ویژگی ها:

  • پایه کد واحد برای همه سیستم عامل ها؛

  • هر کنترل (جزء بصری) می تواند یک ظرف (والد) برای اجزای دیگر باشد.

  • وجود یک آرایش نسبی بسیار پیشرفته (20 نوع) از اجزاء بر روی فرم.

  • LiveBinding به شما امکان می دهد هر نوع داده یا اطلاعات را به هر رابط کاربری یا اشیاء گرافیکی متصل کنید.

  • وجود سبک های فرم / جزء؛

  • پیش‌نمایش چند دستگاه به شما امکان می‌دهد نمایش بصری را برای هر یک از پلتفرم‌ها سفارشی کنید.

  • FireUI Live Preview - نمای برنامه را در دستگاه های واقعی در زمان واقعی نمایش می دهد.

توانایی ها:

  • استفاده از API بومی هر یک از پلتفرم‌ها و همچنین امکان فراخوانی کتابخانه‌های بومی شخص ثالث؛

  • تعامل با تمام سنسورها (GPS، شتاب سنج، قطب نما، بلوتوث (از جمله LE) و دیگران).

  • پشتیبانی از اعلان‌های فشار، اینترنت اشیا؛

  • پشتیبانی از درخواست های HTTP ناهمزمان؛

  • پشتیبانی از اکثر پایگاه های داده (MsSQL، MySql، Oracle، PostgreSQL، MongoDB، و غیره)؛

  • کار با Cloud Service (Amazon، Azure)؛

  • پشتیبانی از خدمات اندروید

معایب (در حال حاضر):

  • عدم پشتیبانی برای سفارشی سازی کلاس های بومی؛

  • اجرای چیزهای خاص یا غیرممکن است (ویجت ها، برنامه های افزودنی (iOS) و غیره) یا رقص با تنبور ضروری است (سرویس پس زمینه، پیام پخش و غیره).

  • سفارشی سازی صفحه نمایش چلپ چلوپ (صفحه اولیه) به زبان ساده، خیر.

  • کنترل‌های FMX از رندر خود (تجسم، ترسیم) استفاده می‌کنند که کاملاً از نظر بصری شبیه به بومی است.

  • استفاده از کنترل های بومی با حرکات بزرگ بدن همراه است.

  • با تودرتو بزرگ اجزاء، چیزهای باورنکردنی رخ می دهد: برنامه در مکان های مختلف خراب می شود، تمرکز از بین می رود، یخ می زند و غیره.

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

  • توصیف خطاها در سیستم عامل های تلفن همراه به "خطای 0x00000X" بی فایده کاهش می یابد.

  • زمان تدوین مایل است برای پروژه های متوسط ​​و بزرگ بهترین باشد.

  • نیاز به استفاده از یک فایل برای اصلاح برنامه های تلفن همراه برای هر پلتفرم؛

  • عدم پشتیبانی از معماری اتم اینتل؛

  • قیمت نامناسب در مقایسه با رقبا

طرفداران:

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

  • وجود تعداد زیادی مؤلفه رایگان و تجاری؛

  • سرعت برنامه بسیار نزدیک به بومی است.

  • یک ویرایشگر بصری بسیار پیشرفته و به طور کلی محیط، وجود سبک ها.

  • توانایی آزمایش برنامه در Win و تنها پس از آن استقرار آن در دستگاه ها، که تا حد زیادی سرعت توسعه را افزایش می دهد.

  • تغییر حالت/پلتفرم با تکان دادن مچ؛

  • PAServer تعامل آسان با MacO ها را هنگام توسعه برای سیستم عامل اپل فراهم می کند.

  • پشتیبانی از گرافیک سه بعدی خارج از جعبه

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

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

اما در انجام این کار مشکلی پیش آمد. بنا به دلایلی، تصمیم گرفتم که فقط نیاز به اجرای یک پروژه کاری نه چندان پیچیده دارم.

برای توضیح اینکه چرا این برای من مشکل ساز شد، کمی انحراف (یکی می خواهد بنویسد، غنایی) نیاز دارد. سفری به گذشته من به عنوان یک توسعه دهنده. برخی از دیدگاه های من در مورد برنامه نویسی با استفاده از دلفی را توضیح دهید.

باید بگم که استفاده از دلفی رو روی ویندوز 3.1 یعنی از نسخه اول شروع کردم. و از آن به بعد مشغول مطالعه VCL هستم. به اصطلاح در اصل مطالعه شده است. کدهای منبع مشاهده، آدرس‌دهی، ردیابی. دوباره و دوباره.

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

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

در اصل من این همسویی را درک می کنم. دوره ای برای چند پلتفرم و مهمتر از آن برای کراس پلتفرم گذرانده شده است. بالاخره VCL چیست؟ کتابخانه اجزای بصری کتابخانه اجزای بصری شما ممکن است با این موافق نباشید. به عنوان مثال، من همیشه بسیاری از مؤلفه‌های غیر بصری را در نظر می‌گرفتم، و نه مؤلفه‌ها، بلکه فقط کلاس‌ها، بخشی جدایی ناپذیر از VCL، و تعداد زیادی کلاس و مؤلفه شخص ثالث - ادامه، توسعه VCL. خوب، من نمی توانم وارثان TDataset را جزئی از VCL در نظر بگیرم. اگر چه، به عنوان مثال، عبارت DBExpress Library می گوید که به عنوان یک VCL نیست. ظاهراً Embarcadero واقعاً VCL یکپارچه را از دیدگاه من به تعدادی کتابخانه جداگانه تقسیم می کند. نه، البته، نه کاملاً جدا، اما با این وجود. و اگر این دیدگاه را داشته باشید، FireMonkey برای جایگزینی بخش بصری VCL در نظر گرفته شده است (چگونه باید کتابخانه کامل کلاس و مؤلفه، شاید Borland Component Library را نام ببرم؟).

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

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

بسیاری به یاد دارند که سعی کردند بسازندکراس پلتفرم نه تنها کتابخانه، بلکه خود دلفی. به موازات دلفی 6، محصول Kylix و کتابخانه CLX منتشر شد. همه اینها برای اینکه بتوانیم برای لینوکس توسعه دهیم انجام شد. با این حال، لینوکس بسیاری از مفاهیم اولیه پنجره سازی رابط کاربری گرافیکی را که ویندوز دارد، ندارد. رابط پنجره برای لینوکس به طور کلی یک پدیده بومی نیست. این یک برنامه اختیاری است. و مجبور شدم نوعی کتابخانه مصنوعی بنویسم. با کمک آن امکان نوشتن برنامه ای هم برای ویندوز و هم برای لینوکس وجود داشت. با این حال، هنوز آن احساس را به یاد می‌آورم، نه ناامیدی، بلکه ناراحتی آزاردهنده‌ای که وقتی سعی کردم از آنالوگ‌های اجزای بصری CLX استفاده کنم، تجربه کردم. من شروع به دلتنگی های زیادی کردم. کاری که من در هنگام توسعه با VCL بدون فکر انجام می‌دادم، با استفاده از CLX دشوار، بسیار متفاوت یا به سادگی غیرممکن بود.

هنگام تغییر از BDE به DBExpress تقریباً همین احساس را داشتم. قدیمی، آشنا از Field Test-a BDE (Borland در آن زمان قبلاً از آن در Quattro Pro برای ویندوز و در Paradox برای Windows استفاده می کرد و ODAPI نامیده می شد و سپس IDAPI و برش بالاتر بود، به نظر من ODBC مایکروسافت) فناوری منسوخ اعلام شد، که باید جای خود را در پروژه های جدید به یک کتابخانه جدید بدهد. من همیشه در ابتدا چیزی را در DBExpress گم می کردم، به خصوص دانش.

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

اکنون، شاید کمی واضح‌تر شود که چرا تصمیم برای نوشتن یک پروژه کوچک کاری با استفاده از FireMonkey مشکلاتی را به همراه داشت. سال هاست که در توسعه پروژه ها، پروژه ها و پروژه ها، یک کلیشه خاص شکل گرفته است، یک الگوی مشخص از اینکه چه کاری و چگونه باید انجام داد. و در مورد من، مجبور شدم با این واقعیت روبرو شوم که الگو باید تغییر کند. زیرا شما نمی توانید تمام آنچه را که به استفاده از VCL عادت کرده اید به پروژه ای که بر روی FireMonkey ساخته شده است منتقل کنید.

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

خوب، یک نکته مهم دیگر. معمولاً چه نوع پروژه هایی باید در محل کار انجام شود، اگر (کار) مربوط به نوشتن کامپایلرها، سیستم های مدل سازی یا هر چیز بسیار علمی دیگری نباشد؟ من فکر می‌کنم که برای بیشتر آنها در مورد توسعه چیزی است که شامل استفاده از پایگاه‌های داده است. علاوه بر این، چیزی بسیار علمی نیز می تواند از خدمات ارائه شده توسط DBMS استفاده کند.

اینجا یک کمین دیگر در انتظارم بود. بنا به دلایلی، وقتی در عمل متوجه شدید که FireMonkey حاوی عناصر متمرکز بر کار با داده های ذخیره شده در پایگاه داده نیست، برای این کار کاملاً آماده نیستید (به بیان ساده). اگرچه من قبلاً بارها در مورد این مطلب خوانده ام و شما می دانید (به لحاظ نظری) از چه چیزی باید استفاده کنید. این در مورد Live Bindings است.

من نمی خواهم وارد بحثی در مورد اینکه آیا برنامه نویسان جالب واقعی باید از مؤلفه های db-aware استفاده کنند یا نه.نمایش، ویرایش و در نهایت ذخیره کردن وارد بحث شوم. که باز هم نه بد است و نه خوب. فقط برای من اینطوری شد

این اولین پست برداشت من را به پایان می رساند. در ردیف بعدی داستان هایی در مورد آنچه و چگونه آنها در حین کار بر روی پروژه بر آن غلبه کردند وجود دارد.

مقالات مرتبط