كيفية تحويل موقع الويب الخاص بك إلى تطبيق جوال مع 7 خطوط من JSON

نهج جديد لمزج Web Engine في التطبيقات الأصلية

ماذا لو أخبرتك بخطوط JSON السبعة أعلاه ، الملونة باللون البرتقالي ، كل ما تحتاجه لتحويل موقع ويب إلى تطبيق جوال؟ لا حاجة لإعادة كتابة موقع الويب الخاص بك باستخدام بعض API API فقط لجعله يتصرف مثل تطبيق الهاتف المحمول. ما عليك سوى إحضار موقعك الحالي كما هو ، ودمجه في تطبيق محلي مع مرجع بسيط لعنوان URL.

وماذا لو ، فقط من خلال تعديل ترميز JSON قليلاً ، يمكنك الوصول إلى جميع واجهات برمجة التطبيقات الأصلية ومكونات واجهة المستخدم الأصلية ، بالإضافة إلى انتقالات العرض الأصلية خارج الصندوق؟

إليك ما يبدو عليه مثال بسيط في العمل:

لاحظ كيف قمت بتضمين صفحة ويب github.com ولكن باقي التخطيط هو جميع مكونات واجهة المستخدم الأصلية ، مثل رأس التنقل وشريط علامة التبويب السفلي. ويتم الانتقال تلقائيًا تلقائيًا دون الحاجة إلى إعادة كتابة موقع الويب باستخدام أي واجهات برمجة تطبيقات.

قبل أن أشرح كيف ، قد تسأل: "هذا رائع ، ولكن هل يمكنك فعل أي شيء ذي معنى بخلاف عرض صفحة الويب في إطار تطبيق أصلي؟"

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

إليك أحد الأمثلة:

لاحظ أن هذا العرض يحتوي على:

  1. رأس تنقل أصلي ، كامل مع وظيفة الانتقال المضمنة
  2. عرض ويب ، والذي يتضمن تطبيق ويب لمولد رمز الاستجابة السريعة
  3. مكون إدخال دردشة أصلي في الأسفل

يمكن وصف كل هذا بمجرد تعديل بعض سمات ترميز JSON التي رأيناها أعلاه.

أخيرًا ، لاحظ أن رمز الاستجابة السريعة يتغير عند إدخال شيء ما من إدخال الدردشة. يؤدي إدخال الدردشة إلى تشغيل وظيفة JavaScript داخل تطبيق الويب لرمز الاستجابة السريعة الذي يعيد إنشاء الصورة.

لم يحاول أي إطار لتطوير التطبيقات حل هذه المشكلة الأساسية المتمثلة في "التكامل السلس لعرض الويب في التطبيقات الأصلية" لأنهم يركزون جميعًا على اختيار إما 100٪ أصلي أو 100٪ جانب HTML5.

عندما تسمع شخصًا يتحدث عن مستقبل تطبيقات الهاتف المحمول ، فربما ستسمعهم يتحدثون عن "هل سيكون أسلوب HTML5 هو الفائز؟ أم أنها ستكون أصلية؟ "

لا أحد منهم يرى الأصلي و html كشيء يمكن أن يتعايش ، علاوة على ذلك ، يخلق التآزر ويحقق أشياء لا يمكن تحقيقها بسهولة خلاف ذلك.

في هذه المقالة سأشرح:

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

لماذا تستخدم HTML في تطبيق أصلي؟

قبل المضي قدمًا ، دعنا نناقش أولاً ما إذا كانت هذه فكرة جيدة ، ومتى قد ترغب في اتباع هذا النهج. فيما يلي بعض حالات الاستخدام المحتملة:

1. استخدم الميزات الأصلية للويب

قد يتم تنفيذ بعض أجزاء تطبيقك بشكل أفضل باستخدام محرك الويب. على سبيل المثال ، Websocket هي ميزة أصلية على الويب مصممة لبيئة الويب. في هذه الحالة ، من المنطقي استخدام محرك الويب المضمن (WKWebView لنظام iOS و WebView لنظام Android) بدلاً من تثبيت مكتبة جهة خارجية "تحاكي" Websocket بشكل أساسي.

لا حاجة لتثبيت كود إضافي لمجرد القيام بشيء يمكنك القيام به مجانًا ، مما ينقلنا إلى النقطة التالية.

2. تجنب الحجم الثنائي الكبير

قد ترغب في دمج الميزات التي تتطلب مكتبة ضخمة من جهة خارجية بسرعة.

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

3. لا توجد مكتبة متنقلة موثوقة

بالنسبة لبعض التقنيات المتطورة ، لا يوجد تطبيق محمول موثوق به ومستقر حتى الآن.

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

4. إنشاء تطبيقات جزئية ، قائمة على الويب

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

على سبيل المثال ، قد يكون لديك صفحة ويب واحدة معقدة للغاية بحيث لا يمكن تحويلها على الفور إلى تطبيق جوال ، ولكن يمكن تحويل بقية موقعك بسهولة.

في هذه الحالة ، سيكون من اللطيف إذا كانت هناك طريقة لبناء معظم التطبيق أصلاً ، ولكن لصفحة الويب المعقدة هذه ، قم بدمجها بسلاسة في التطبيق بصيغة HTML.

كيف يعمل؟

جيسونيت

Jasonette هو نهج مفتوح المصدر قائم على الترميز لإنشاء تطبيقات أصلية عبر الأنظمة الأساسية.

إنه مثل متصفح الويب ، ولكن بدلاً من تفسير ترميز HTML في صفحات الويب ، فإنه يفسر ترميز JSON في التطبيقات الأصلية على iOS و Android.

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

يمكنك معرفة المزيد عن Jasonette هنا.

في حين أن Jasonette في صميمه يدور حول بناء تطبيقات أصلية ، فإن هذه المقالة الخاصة تدور حول دمج HTML في المحرك الأصلي الأساسي ، لذلك دعونا نتحدث عن ذلك.

حاوية ويب Jasonette

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

لكن دمج طرق عرض الويب في تطبيق محلي هو عمل صعب. يتطلب التكامل السلس:

  1. يجب دمج عرض الويب كجزء من التخطيط الأصلي: يجب دمج عرض الويب في التطبيق كجزء من التخطيط الأصلي ويتم التعامل معه تمامًا مثل أي مكونات واجهة مستخدم أصلية أخرى. وإلا سيشعر بالضيق ، وسيشعر تمامًا كما هو - موقع ويب.
  2. يمكن للتطبيق الأصلي التحكم في حاوية الويب الفرعية: يجب أن يكون التطبيق الرئيسي قادرًا على التحكم بحرية في عرض الويب الفرعي.
  3. يمكن لحاوية الويب الفرعية تشغيل الأحداث الأصلية على التطبيق الرئيسي: يجب أن يكون التطبيق الفرعي قادرًا على تشغيل أحداث التطبيق الرئيسي لتشغيل واجهات برمجة التطبيقات الأصلية.

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

كان هذا مفيدًا بالفعل ، ولكن لا يزال هناك قيود على عدم التفاعل.

تعذر على تطبيق الوالدين التحكم في حاوية الويب الفرعية ، ولم يتمكن الطفل من إخطار الوالد بأي حدث ، مع إبقاء حاوية الويب معزولة تمامًا عن العالم الخارجي.

ج. Jasonette Web Container 2.0: اجعلها تفاعلية

بعد إصدار الإصدار الأول ، جربت الجزء الثاني من اللغز - إضافة التفاعل إلى حاوية الويب.

يشرح القسم التالي الحلول التي تمت إضافتها لجعل حاويات الويب الثابتة مسبقًا تفاعلية ، مما يجعلها أكثر قوة بشكل ملحوظ.

التنفيذ: حاوية الويب التفاعلية

1. تحميل عن طريق URL

مشكلة

في الإصدار 1 سابقًا ، لاستخدام حاوية الويب كمكون لعرض الخلفية ، كان عليك أولاً تعيين $ jason.body.background.type على "html" ثم ترميز نص HTML تحت $ jason.body.background.text سمة مثل هذا:

{"$ jason": {"head": {...}، "body": {"background": {"type": "html"، "text": " مرحبا بالعالم "}}}}

بطبيعة الحال ، أراد الأشخاص أن يكونوا قادرين على إنشاء الحاوية باستخدام عنوان URL على الويب بدلاً من الاضطرار إلى ترميز نص HTML بالكامل في سطر واحد.

المحلول

تمت إضافة حاوية الويب 2.0 سمة url. يمكنك تضمين ملف محلي: // HTML مثل هذا (يتم تحميله من ملف HTML المحلي الذي تشحنه مع التطبيق):

{"$ jason": {"head": {...}، "body": {"background": {"type": "html"، "url": "file: //index.html"}} }}

أو تضمين http [s]: // URL مثل هذا (يتم تحميله من HTML بعيد):

{"$ jason": {"head": {...}، "body": {"background": {"type": "html"، "url": "https://news.ycombinator.com" }}}}

2. التطبيق الرئيسي <=> اتصال حاوية الويب

مشكلة

في السابق ، كانت حاويات الويب فقط لعرض المحتوى وليس التفاعلية. هذا يعني أنه لا يوجد أي مما يلي ممكن:

  1. Jasonette => حاوية الويب: اتصل بوظائف JavaScript داخل حاوية الويب من Jasonette.
  2. حاوية الويب => Jasonette: استدعاء API الأصلي من رمز حاوية الويب.

كل ما يمكنك فعله هو عرض حاوية الويب. كان هذا مشابهًا لكيفية تضمين إطار iframe في صفحة الويب ، ولكن لم يكن لصفحة الويب الرئيسية حق الوصول إلى ما كان داخل iframe.

المحلول

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

لتحقيق ذلك ، توصلت إلى قناة اتصال قائمة على JSON-RPC بين التطبيق الرئيسي وحاوية الويب الفرعية. نظرًا لأن كل شيء على Jasonette يتم التعبير عنه في كائنات JSON ، فمن المنطقي تمامًا استخدام تنسيق JSON-RPC القياسي كبروتوكول اتصال.

لإجراء استدعاء دالة JavaScript في حاوية الويب ، نعلن عن إجراء يسمى $ agent.request:

{"type": "$ agent.request"، "options": {"id": "$ webcontainer"، "method": "login"، "params": ["username"، "password"]}}

$ agent.request هي واجهة برمجة التطبيقات الأصلية التي تشغّل طلب JSON-RPC في حاوية الويب. لاستخدامه ، يجب علينا تمرير كائن خيارات كمعلمة له.

كائن الخيارات هو طلب JSON-RPC الفعلي الذي سيتم إرساله إلى حاوية الويب. دعونا نلقي نظرة على معنى كل سمة:

  • المعرّف: حاوية الويب مبنية فوق بنية ذات مستوى أقل تسمى وكيل. عادةً يمكنك الحصول على وكلاء متعددين لعرض واحد ، ويمكن أن يكون لكل وكيل معرفه الفريد. لكن حاوية الويب هي نوع خاص من الوكيل الذي لا يمكن أن يحتوي إلا على معرف $ webcontainer ، ولهذا السبب نستخدم هذا المعرّف هنا.
  • الطريقة: اسم وظيفة JavaScript للاتصال
  • params: مجموعة من المعلمات لتمريرها إلى وظيفة JavaScript.

سيبدو الترميز الكامل كالتالي:

{"$ jason": {"head": {"Actions": {"$ load": {"type": "$ agent.request"، "options": {"id": "$ webcontainer"، "method ":" login "،" params ": [" alice "،" 1234 "]}}}}،" body ": {" header ": {" title ":" Web Container 2.0 "}،" background ": { "type": "html"، "url": "file: //index.html"}}}}

هذا الترميز يقول:

عند تحميل العرض ($ jason.head.actions. $ load) ، يمكنك تقديم طلب JSON-RPC إلى وكيل حاوية الويب ($ agent.request) حيث يتم تحديد الطلب ضمن الخيارات.

يتم تعريف حاوية الويب تحت $ jason.body.background ، والتي تقوم في هذه الحالة بتحميل ملف محلي يسمى file: //index.html.

ستبحث عن وظيفة JavaScript تسمى تسجيل الدخول وتمرير الوسيطتين تحت المعلمات ("alice" و "1234")

تسجيل الدخول ("أليس" ، "1234")

لقد شرحت فقط كيف يمكن للتطبيق الرئيسي تشغيل مكالمات وظيفة JavaScript لحاوية الويب الفرعية ، ولكن يمكنك أيضًا القيام بالعكس والسماح لحاوية الويب بتشغيل واجهة برمجة التطبيقات الأصلية للتطبيق الأصلي.

لمعرفة المزيد ، راجع وثائق الوكيل.

مثال

لنعد إلى مثال رمز الاستجابة السريعة الذي قمت بمشاركته لفترة وجيزة أعلاه:

  1. مكون إدخال التذييل أصلي 100٪.
  2. يتم إنشاء رمز الاستجابة السريعة بواسطة حاوية الويب كتطبيق ويب.
  3. عندما يدخل المستخدم شيئًا ويضغط على "إنشاء" ، فإنه يستدعي إجراء $ agent.request إلى وكيل حاوية الويب ، مع استدعاء وظيفة JavaScript "qr"

يمكنك التحقق من المثال هنا.

3. حقن البرنامج النصي

مشكلة

في بعض الأحيان قد ترغب في إدخال شفرة جافا سكريبت ديناميكيًا في حاوية الويب بعد انتهاء تحميل HTML الأولي.

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

حتى إذا كنت لا تبني متصفح ويب ، فقد ترغب في استخدام طريقة إدخال البرنامج النصي عندما تريد سلوكًا مخصصًا لعنوان URL لا يمكنك التحكم في محتواه. الطريقة الوحيدة للتواصل بين التطبيق الأصلي وحاوية الويب هي من خلال $ agent API. ولكن إذا لم تتمكن من تغيير محتوى HTML ، فإن الطريقة الوحيدة لإضافة واجهة $ agent إلى حاوية الويب هي من خلال الحقن الديناميكي.

المحلول

كما ذكر في القسم السابق ، فإن حاوية الويب $ jason.body.background مجرد وكيل آخر. هذا يعني أنه يمكنك استخدام نفس طريقة $ agent.inject المتاحة للوكلاء العاديين.

4. URL انقر فوق معالجة

في الماضي ، كانت هناك طريقتان فقط يمكن لحاوية الويب التعامل مع نقرات الروابط:

  1. للقراءة فقط: تعامل مع حاوية الويب على أنها للقراءة فقط وتجاهل جميع الأحداث مثل اللمس أو التمرير. تكون جميع حاويات الويب للقراءة فقط ما لم تخبرها أن تتصرف مثل متصفح عادي ، كما هو موضح أدناه.
  2. سلوك المتصفح العادي: السماح للمستخدمين بالتفاعل مع الصفحة من خلال التصرف مثل المتصفح العادي. يمكنك التصريح بذلك عن طريق تعيين "type": "$ default" كسمة إجراء.

مشكلة

كلاهما حلول "الكل أو لا شيء".

  • في حالة "للقراءة فقط" ، يتم تجاهل جميع تفاعلاتك تمامًا بواسطة حاوية الويب.
  • في حالة "سلوك المتصفح العادي" ، تعمل حاوية الويب فعليًا كمتصفح. عندما تنقر على رابط ، فإنه سيرسل لك هذا الرابط فقط عن طريق تحديث الصفحة تمامًا مثل صفحة الويب. لم يكن هناك طريقة لاختطاف النقرة واستدعاء بعض API الأصلي.

المحلول

باستخدام حاوية الويب الجديدة ، يمكنك الآن إرفاق أي إجراء على حاوية الويب $ jason.body.background للتعامل مع أحداث النقر على الرابط.

لنلقي نظرة على مثال:

{"$ jason": {"head": {"Actions": {"displayBanner": {"type": "$ util.banner"، "options": {"title": "Clicked"، "description": "رابط {{$ jason.url}} نقر!" }}}}، "body": {"background": {"type": "html"، "url": "file: //index.html"، "action": {"مشغل": "displayBanner"} }}}}

هنا قمنا بإرفاق "المشغل": "displayBanner" بحاوية الويب. وهذا يعني أنه عندما ينقر المستخدم على أي رابط في حاوية الويب ، فإنه سيؤدي إلى إجراء displayBanner بدلاً من السماح لعرض الويب بالتعامل معه.

أيضًا ، إذا نظرت إلى إجراء displayBanner ، فستلاحظ المتغير $ jason. في هذه الحالة ، سيتم تمرير الرابط الذي تم النقر عليه من خلال متغير $ jason. على سبيل المثال ، إذا نقرت على عنوان URL باسم "https://google.com" ، فسيكون $ jason بالقيمة التالية:

{"url": "https://google.com"}

هذا يعني أنه يمكنك تشغيل إجراءات مختلفة بشكل انتقائي عن طريق التحقق من قيمة $ jason.url.

دعنا نأخذ مثالاً آخر حيث نقوم بتطبيق متصفح ويب مخصص:

{"$ jason": {"head": {"Actions": {"handleLink": [{"{{#if $ jason.url.indexOf ('signin')! == -1}}": {" اكتب ":" $ href "،" خيارات ": {" url ":" file: //key.html "}}} ، {" {{#else}} ": {" type ":" $ default "} }]}} ، "body": {"background": {"type": "html"، "url": "file: //index.html"، "action": {"مشغل": "handleLink"} }}}}

نختبر ما إذا كان عنوان URL يحتوي على تسجيل الدخول إلى السلسلة ثم ننفذ إجراءين مختلفين بناءً على النتيجة.

  1. إذا كان يحتوي على تسجيل دخول ، فإنه يفتح طريقة عرض جديدة لرعاية تسجيل الدخول محليًا.
  2. إذا لم يكن يحتوي على تسجيل دخول ، فقم فقط بتشغيل الإجراء "type": "$ default" بحيث يتصرف مثل المتصفح العادي.

مثال للاستخدام

بناء متصفح ويب مخصص

يمكننا الآن الاستفادة من حقيقة أن حاوية الويب الجديدة يمكنها:

  1. خذ سمة url لتحميل نفسها ، وتعمل كمتصفح كامل
  2. تعامل بشكل انتقائي مع نقرات الرابط حسب عنوان URL

يمكننا أيضًا إنشاء تطبيق مستعرض ويب مخصص مع اثني عشر سطرًا من JSON. نظرًا لأنه يمكننا الآن الاستيلاء على كل نقرة على الرابط ، يمكننا إلقاء نظرة على $ jason.url وتشغيل أي إجراءات نريدها اعتمادًا على عنوان URL.

على سبيل المثال ، ألق نظرة على المثال أدناه:

على الجانب الأيسر ، نرى أن النقر على رابط يتصرف مثل المتصفح العادي ("type": "$ default")

على الجانب الأيمن ، نرى أن النقر على رابط يؤدي إلى انتقال أصلي إلى عرض JASON آخر.

يمكن تحقيق كل هذا من خلال إطلاق إجراءات مختلفة بشكل انتقائي بناءً على $ jason.url.

الخطوة 1. إرفاق إجراء باسم الزيارة إلى حاوية الويب مثل هذا:

{... "body": {"background": {"type": "html"، "url": "https://news.ycombinator.com"، "action": {"trig": "visit" }}}}

الخطوة 2. قم بتشغيل الإجراءات ذات الصلة داخل الزيارة ، على أساس $ jason.url

في الكود التالي ، نتحقق مما إذا كان $ jason.url يتطابق مع الأحدث والعرض والسؤال وما إلى ذلك (إنها روابط عنصر القائمة العلوي). إذا حدث ذلك ، فإننا نترك حاوية الويب تتصرف مثل المتصفح العادي عن طريق تعيين "type": "$ default"

إذا لم يتطابقوا مع النمط ، فنحن ننقل $ href الأصلي إلى عرض جديد ونمرر الرابط الذي تم النقر عليه كمعلمة.

... "الإجراءات": {"زيارة": [{"{{#if /\\/(newest|show|ask)$/.test($jason.url)}}": {"type": " $ default "}} ، {" {{#else}} ": {" type ":" $ href "،" options ": {" url ":" https://jasonette.github.io/Jasonpedia/webcontainer/ agent / hijack.json "،" preload ": {" background ":" #ffffff "}،" options ": {" url ":" {{$ jason.url}} "}}}}]} ،

تحقق من ترميز JSON الكامل لمتصفح الويب هنا (إنه 48 سطرًا فقط!).

تطبيق "هجين" فوري

عندما يتحدث الأشخاص عادةً عن التطبيقات "المختلطة" ، فإنهم غالبًا ما يعنيون تطبيقات ويب HTML ملفوفة داخل إطار تطبيق أصلي.

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

يجب أن يكون التقاطع بين العرض المستند إلى الويب والعرض الأصلي سلسًا للغاية بحيث يصعب معرفة من أين يبدأ وينتهي.

في هذا المثال ، قمت بإنشاء تطبيق يعرض jasonbase.com في حاوية ويب كعرض الصفحة الرئيسية.

Jasonbase عبارة عن خدمة استضافة JSON مجانية أنشأتها لاستضافة ترميز JSON بسهولة لتطبيقات Jasonette.

بطبيعة الحال ، إنه مجرد موقع ويب ، لكني قمت بتضمينه في Jasonette بحيث أنه عند النقر فوق الرابط ، بدلاً من فتح صفحة ويب ، فإنه ينتقل $ href الأصلي إلى عرض JASON الأصلي.

لم يكن عليّ لمس أي رمز من Jasonbase.com لإنشاء هذا التطبيق.

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

يمكنك التحقق من الرمز هنا.

استنتاج

في رأيي ، ما يجعل كل هذا العمل رائعًا هو أن كل شيء يتم الاهتمام به على مستوى الإطار. يتم رعاية كل العمل الشاق وراء الكواليس.

بدلاً من وضع العبء على مطوري التطبيقات لتنفيذ كل ما يلي من البداية:

  • تضمين عرض ويب في التخطيط الأصلي
  • قم بإنشاء جسر JavaScript بحيث يمكن للتطبيق إجراء مكالمات وظيفية في عرض الويب
  • إنشاء بنية التعامل مع الأحداث الأصلية بحيث يمكن لعرض الويب تشغيل الأحداث الأصلية على التطبيق الرئيسي

كان الحل هو إنشاء تجريد يتكون من:

  1. لغة الترميز التعريفي: لوصف كيفية تضمين عرض ويب في تطبيق أصلي
  2. بروتوكول الاتصال (JSON-RPC): للسماح بالتفاعلات الميتة البسيطة بين التطبيق وطرق عرض الويب الفرعية الخاصة به.

لا أدعي أن هذا النهج هو الحل النهائي لحل كل شيء ، ولكن يسعدني أن أقول إن هذا كان حلاً رائعًا لقضيتي الخاصة.

كنت أحاول إنشاء تطبيق يعتمد على تقنية فائقة الحافة لا تحتوي على تطبيقات جوال مستقرة وموثوقة (وليس من الواضح ما إذا كان هناك تطبيق للجوال بسبب طبيعة البروتوكول). لحسن الحظ أنه يحتوي على تطبيقات JavaScript حتى أتمكن من دمجه بسهولة في التطبيق دون أي متاعب.

بشكل عام ، لقد كان رائعًا وأنا راضٍ عن كيفية ظهوره. الوثائق محدثة لتعكس جميع الميزات الجديدة ، لذلك لا تتردد في البحث واللعب.

تنويه: مع القوة العظيمة تأتي مسؤولية كبيرة

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

قد يأخذ البعض هذا وينشئون تطبيقًا كاملًا باستخدام طرق عرض الويب فقط ، ولكن بعد ذلك ستنتهي بتطبيق يكون في الأساس مجرد موقع ويب ، وهو ما يهزم الغرض من إنشاء تطبيق مخصص.

أؤكد أنني لا أقول أنه يجب عليك دائمًا إنشاء تطبيقات باستخدام كل من HTML والأصلي. أنا أقول أن هذا يمكن أن يكون مفيدًا جدًا للعديد من الأشخاص في مواقف مختلفة. فقط لا تفرط في ذلك.

اتبع على طول لمعرفة المزيد

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

من الآن فصاعدًا ، أخطط لمشاركة المزيد من حالات الاستخدام والبرامج التعليمية هذه ، لذلك إذا كنت مهتمًا ، فيرجى المتابعة على الوسيط أو تويتر.