ترقية WPF الى كاكاو (و / أو العكس بالعكس)

Question

وأنا في المراحل الأولى من خلق برنامج لmISV ليكون. البرنامج هو تطبيق سطح المكتب وعلى المدى الطويل أريد أن يكون نسخة أصلية لكل من ويندوز وOS X (لقد ونظرت عبر منصة مختلف واجهات برمجة التطبيقات، وأيا منها تلبية احتياجات بلدي). على الرغم من البداية، وأنا لا أعتقد أنه من المنطقي أن تطوير لمنصتي في آن واحد. مع أخذ ذلك في الاعتبار، لقد كنت تبحث في WPF ويندوز والكاكاو لOS X، ويبدو أنها مماثلة.

لقد كان أي شخص قد تجربة ترقية واحدة إلى أخرى؟ هل هناك معينة تقنيات / نماذج لمتابعة من شأنها أن تجعل ترقية أسهل؟ تجاهل الاعتبارات التجارية، تنصحين تطوير على واحد منهم أولا؟

Answer 1

وأنا حاليا العمل على أدوات ترقية في هذا المجال ولها العديد من سنوات الخبرة كثيرا ما المؤلمة في إما باستخدام أو كتابة أطر عبر منصة على ويندوز وماك.

وكانت واحدة من أكبر المشاكل في الماضي رفض أبل لفتح شكل بنك الاستثمار القومي لالكاكاو (كانت حبيبات الكربون ملفات XML المفتوحة منذ سنوات). التي غيرت مع كسكودي 3 و .xib شكل ، وأوضح كذلك عن طريق فريزر سبيرس .

وعلى المستوى التصميم الأساسي، على الأقل، وهناك الآن فرصة لأتمتة ترقية من صيغة XML واحد إلى آخر. أنا أعتبر WPF (XAML) كمنظف ولذا فإنني أستخدم أنه شكل قاعدة بلدي والهجرة الى كاكاو.

وعندما يتعلق الأمر إلى رمز وراء، في حين يمكنك استخدام C # ضمن مونو، و CocoaSharp يبدو المشروع إما المتعثرة أو بطيئة جدا وأنا لا أوصي به.

إذا كنت مرتاحا مع C ++، النظر في وجود الكثير من المنطق ممكن في C ++ مع طبقة رقيقة منصة محددة في C # و الهدف-C.

وثمة نهج آخر يستحق التحقيق يستخدم لغة ديناميكية مثل بايثون أو روبي. لست متأكدا وهو أكثر نضجا في الوقت الحاضر بين و IronPython و <لأ href = "HTTP: / /www.ironruby.net/ "يختلط =" نوفولو noreferrer "> آيرن روبي لكن كلا معتمدة الآن من قبل الناس مايكروسوفت. على الجانب الكاكاو، وأعتقد أن مرونة تركيب روبي ينتصر و RubyCocoa ربما التجاوز <أ href ل = "http://pyobjc.sourceforge.net/" يختلط = "نوفولو noreferrer"> PyObjC .

وعلى خلاف ذلك، عمل في C # و الهدف-C والحفاظ على قاعدتين كود مستقلة تماما مع تصاميم متطابقة. لحسن الحظ الأطر لها دلالات مماثلة لمعظم الأشياء، وخاصة إذا كنت الاستفادة من الارتباطات.

Answer 2

وأعتقد أنك على الطريق الصحيح عن طريق اختيار بيئات النوافذ التي تخص كل منصة. هذا النهج يسمح لك لخلق تجربة المستخدم على كل منصة غير مقيدة التنازلات الملازمة لعبر منصة الأدوات النوافذ.

وخطوة أولى جيدة لكسر التصميم الخاص بك إلى أسفل إلى قسمين: منصة محددة ومنصة عناصر محايدة. يمكنك وضع بالفعل أي رمز UI في عمود معين منصة، ولكن ربما التطبيق الخاص بك وسوف تحتاج إلى بعض المثابرة البيانات التي يمكن كتابتها في منصة محايدة C ++. ما قد تجد مع هذا النهج هو أن هناك قدرا كبيرا من المنطق والبنية التحتية التي يمكن أن تكتب بطريقة منصة محايدة، وترك مجرد واجهة المستخدم والغراء الكود كما منصة محددة.

وكان هناك الحلقة الأخيرة من في وقت متأخر ليلة الكاكاو وتحت عنوان على ترقية التطبيقات الكبيرة إلى منصة ماك . التطبيق الخاص بك قد لا صفها بأنها "كبيرة" ولكن هذا podcast يعطي قدرا كبيرا من المعرفة ترقية كبيرة من شخص ما ان يتم ذلك عدة مرات.

Answer 3

وحسنا. مرة واحدة كنت قد كتبت التطبيق لالكاكاو، فمن الممكن أن الميناء إلى ويندوز. ويمكن القيام بذلك باستخدام gnustep أو <وأ href = "http://www.cocotron.org/" يختلط = "نوفولو noreferrer"> Cocotron .

إذا كنت تفعل ذلك بطريقة أخرى، والمقصود WINE لجعل ترقية أسهل.

وأنا يفضلون إرسال النسخة OSX أولا. وذلك لأن مستخدمي ويندوز ليس لديهم فكرة واضحة عما يريدون تطبيق لتبدو وكأنها. في تجربتي، وهم قادرون تماما للمعاناة من خلال جميع أنواع واجهات المستخدم. الاتساق له قيمة تذكر لهم. وبما أنه لا يوجد اتفاق مشترك، ما ينبغي أن ننظر التطبيق ويندوز مثل، لا شيء يتوقف مستخدمي ويندوز من تروق فعلا تصاميم OSX، وأنها حتى في كثير من الأحيان القيام به. اي تيونز للنوافذ يشبه التطبيق OSX نموذجي جدا وتسمع شكاوى قليلة جدا أنه لن يكون كافيا ويندوز العش.

والذهاب في الاتجاه الآخر، وهذا ليس صحيحا. المستخدمين OSX لديهم تفضيل واضح للتطبيقات الكاكاو والتسامح القليل جدا ل، على سبيل المثال، أشياء مثل GIMP أو إنكسكيب التي تعمل تحت OSX فقط، وكذلك في أي مكان آخر، ولكن تبدو قبيحة بوضوح للعين OSX المدربين.

Answer 4

حسنا، ليس هناك طريق واضحة. أفضل طريقة لاستخدام شيء مثل نمط الموديل عرض المراقب المالي أو بعض الهندسة المعمارية أخرى لفصل منطق الأعمال وهكذا دواليك من العرض التقديمي. ومع ذلك، إلا إذا كنت تستخدم مونو، سيكون هناك رمز صغيرة جدا بالنسبة لك للمشاركة، I think.If كنت تقوم بتطوير WPF ثم تفعل بالتأكيد. NET و، وغيرها من مونو، الهدف C هو أداة البرمجة القياسية تحت Mac OS X.

والحفاظ على التصميم الجيد ويمكن أن يكون أكثر من التعليمات البرمجية الخاصة بك ببساطة أن يكون نسخة الهدف-C من التعليمات البرمجية. NET الخاص بك، والعكس بالعكس بدلا من محاولة العثور على مسار الهجرة.