বিল্ড প্রকারের পণ্য স্বাদ থেকে আলাদা কেন?


173

উপস্থাপনা: এটি কোনও অ্যান্ড্রয়েড অ্যাপে বিল্ড প্রকার এবং পণ্যের স্বাদ কীভাবে ব্যবহার করবেন সে সম্পর্কে কোনও প্রশ্ন নয়। আমি জড়িত বেসিক ধারণা বুঝতে। কোন বিল্ড টাইপের মধ্যে কোন কনফিগারেশন নির্দিষ্ট করা উচিত, কোন পণ্যের স্বাদে কোন কনফিগারেশন নির্দিষ্ট করা উচিত এবং কোনও পার্থক্য আসলে প্রয়োজনীয় কিনা তা এই প্রশ্নটি আরও বোঝার চেষ্টা করার বিষয়ে is

এই সপ্তাহে, আমি অ্যান্ড্রয়েড অ্যাপ্লিকেশনগুলির জন্য গ্রেড কনফিগারেশন সম্পর্কে আরও শিখছি। আমি প্রথমে ভেবেছিলাম পণ্যগুলির স্বাদে বনাম ধরণের ভাল হ্যান্ডেল পেয়েছি, তবে ডকুমেন্টেশনের মধ্যে যত গভীর gotুকলাম ততই বুঝতে পারলাম দুজনের মধ্যে পার্থক্য আমার কাছে মোটেও পরিষ্কার নয়।

যেহেতু এখানে একটি সংজ্ঞায়িত শ্রেণিবদ্ধতা রয়েছে (এই অর্থে যে বিল্ড ধরণের নির্দিষ্ট বৈশিষ্ট্যগুলি পণ্যগুলির স্বাদে উল্লিখিতগুলির চেয়ে বেশি প্রাধান্য পায়) তাই কেন বিল্ড প্রকার এবং পণ্যের স্বাদগুলির মধ্যে পার্থক্য করার প্রয়োজন আছে তা আমি বুঝতে পারি না। পণ্যের বৈশিষ্ট্য ডিএসএল অবজেক্টে সমস্ত বৈশিষ্ট্য এবং পদ্ধতি একীভূত করা ভাল না, এবং তারপরে বিল্ড টাইপটিকে (ডিফল্ট) স্বাদ মাত্রা হিসাবে বিবেচনা করুন?

কিছু দৃ concrete় উদাহরণ যা আমার বিভ্রান্তির দিকে পরিচালিত করেছে:

  • signingConfigসম্পত্তি বিল্ড ধরনের ও পণ্যের স্বাদে উভয় সেট করা যেতে পারে ... কিন্তু minifyEnabled(এবং, আমি অনুমান, shrinkResources?) শুধুমাত্র বিল্ড ধরনের কনফিগার করা যাবে।

  • applicationIdশুধুমাত্র পণ্যের স্বাদে নির্দিষ্ট করা যায় ... এবং applicationIdSuffixকেবল বিল্ড ধরণের ক্ষেত্রেই নির্দিষ্ট করা যায় !?

আসল প্রশ্ন (গুলি) :

উপরের উদাহরণগুলি দেওয়া: বিল্ড প্রকারের বনাম পণ্যগুলির স্বাদের ভূমিকার মধ্যে কোনও স্পষ্ট পার্থক্য রয়েছে?

যদি তা হয় তবে এটি বোঝার সর্বোত্তম উপায় কোনটি?

যদি তা না হয়, তবে অবশেষে বিল্ড প্রকার এবং পণ্যের স্বাদগুলি একক কনফিগারযোগ্য ডিএসএল অবজেক্টে মার্জ করার পরিকল্পনা কী?


55
"কোন বিল্ড টাইপতে কোন কনফিগারেশন নির্দিষ্ট করা উচিত, কোন পণ্যটির স্বাদে কোন কনফিগারেশন নির্দিষ্ট করা উচিত" - বিল্ড প্রকারভেদে আপনার বিকাশের লাইফসাইল (ডিবাগ, "ডগফুড", রিলিজ ইত্যাদি) মডেল তৈরি করুন। পণ্যের স্বাদগুলি আপনার বিতরণ কৌশলটির মডেল করে (গুগল আইএপি বনাম অ্যামাজন আইএপি বনাম ব্ল্যাকবেরি আইএপি, ইত্যাদি)। এগুলি স্বতন্ত্র ধারণা। বাকী হিসাবে, আমি কল্পনা করব যে বাস্তবায়নের সাথে জড়িত প্রযুক্তিগত কারণগুলি রয়েছে যা তারা কীভাবে ডিএসএল সেটআপ করেছিল তা কিছুটা নির্ধারণ করেছিল, এবং তাই কোনও সংযুক্তির পরিকল্পনা থাকলে আমি অবাক হয়ে যাব।
কমনসওয়ার

1
@ কমন্সওয়্যার যা উচ্চ স্তরে প্রচুর অর্থবোধ করে। এবং হ্যাঁ, সম্ভবত ধরণের ক্রম / স্বাদগুলির ক্রমজাতকরণ প্রক্রিয়াটি কীভাবে এবং কখন পুরোটিকে পরিবর্তন করতে পারে তা সীমাবদ্ধ করে applicationId
স্টকেন্ট

উত্তর:


168

@ কমন্সওয়্যার মন্তব্যগুলিতে যা বলেছে তার প্রসারিত করে, মূল ধারণাটি হ'ল বিল্ড প্রকারগুলি আপনার অ্যাপ্লিকেশনের বিভিন্ন বিল্ডের জন্য যা কার্যকরীভাবে আলাদা নয় - যদি আপনার অ্যাপ্লিকেশনটির কোনও ডিবাগ এবং প্রকাশ সংস্করণ থাকে তবে তারা একই অ্যাপ্লিকেশন , তবে একটিতে ডিবাগিং কোড রয়েছে, সম্ভবত আরও লগিং ইত্যাদি and এবং অন্যটি প্রবাহিত এবং অপ্টিমাইজড এবং সম্ভবত প্রোগুয়ার্ডের মাধ্যমে অস্পষ্ট। স্বাদের সাথে, উদ্দেশ্যটি হ'ল অ্যাপটি কোনওভাবেই বিশেষভাবে আলাদা। এর সুস্পষ্ট উদাহরণটি হ'ল আপনার অ্যাপ্লিকেশনটির একটি বিনামূল্যে বনাম একটি অর্থ প্রদান করা সংস্করণ, তবে এটি কোথায় বিতরণ করা হচ্ছে তার ভিত্তিতে বিকাশকারীরা (যা অ্যাপ্লিকেশন বিলিং এপিআই ব্যবহারকে প্রভাবিত করতে পারে) এর ভিত্তিতেও পার্থক্য করতে পারে।

এমন বিকাশকারীগণ রয়েছে যা বিভিন্ন গ্রাহকের জন্য একই অ্যাপের অনেকগুলি এবং বিভিন্ন সংস্করণ তৈরি করে - উদাহরণ হতে পারে একটি সাধারণ অ্যাপ্লিকেশন যা একটি ওয়েব ভিউতে একটি ওয়েব পৃষ্ঠা খোলে, প্রতিটি সংস্করণের জন্য বিভিন্ন URL এবং ব্র্যান্ডিং - এটি একটি স্বাদ ভাল ব্যবহার।

পুনরাবৃত্তি করার জন্য, যদি এটি "একই অ্যাপ্লিকেশন" হয় তবে কিছু ব্যবহারকারীর পরিবর্তন করুন যা শেষ ব্যবহারকারীর পক্ষে গুরুত্বপূর্ণ নয় এবং বিশেষত যদি একটি ব্যতীত সমস্ত রূপগুলি আপনার নিজস্ব পরীক্ষার জন্য এবং বিকাশের ব্যবহারের জন্য থাকে এবং কেবলমাত্র একটি বৈকল্পিক স্থাপন করা হবে শেষ ব্যবহারকারী, তারপরে এটি বিল্ড প্রকারের জন্য ভাল প্রার্থী। যদি এটি "আলাদা" অ্যাপ্লিকেশন এবং একাধিক রূপ ব্যবহারকারীদের কাছে স্থাপন করা হয় তবে সম্ভবত এটি কোনও পণ্যের স্বাদে প্রার্থী।

আপনি ইতিমধ্যে দেখেছেন যে বিল্ড প্রকার এবং স্বাদগুলির মধ্যে কিছু কার্যকারিতা পার্থক্য রয়েছে, এতে কিছু বিকল্প একটির জন্য সমর্থিত হয় তবে অন্যটির পক্ষে নয়। তবে ধারণাগুলি একই রকম হওয়া সত্ত্বেও ভিন্ন এবং এগুলি একত্রিত করার কোনও পরিকল্পনা নেই।


17
ধন্যবাদ, স্কট আমি স্পষ্টতই মনে করি এই পার্থক্যটি অর্থবোধ করে (এবং 'বিল্ড টাইপ' এবং 'পণ্যগুলির স্বাদ' নামগুলি এই ব্যবহারের জন্য উপযুক্ত)। সম্ভবত কেউ applicationIdসমস্যাটি নিম্নরূপে বুঝতে পারে : যেহেতু স্বাদ আপনার অ্যাপ্লিকেশানের "সম্পূর্ণ আলাদা" সংস্করণ উপস্থাপন করে, তাই এটি "সম্পূর্ণরূপে" বিভিন্ন অ্যাপ্লিকেশন আইডিকে নির্দিষ্ট করতে সক্ষম হওয়ার বোধ হয়; তবে, একটি নির্দিষ্ট গন্ধের জন্য, একাধিক বিল্ড প্রকারগুলি সমস্ত "একই" অ্যাপ্লিকেশনটিকে উপস্থাপন করে এবং তাই কেবল অ্যাপ্লিকেশন আইডি প্রত্যয়টি পরিবর্তনের অনুমতি দেওয়া হয় (যার ফলে অ্যাপ্লিকেশন আইডির 'গ্রুপিং' রাখা হয়)।
স্টেকেন্ট

28

বিল্ডটাইপ কীভাবে আমরা আমাদের অ্যাপ্লিকেশনটিকে প্যাকেজ করি তা কনফিগার করে

  • shrinkResources
  • progaurdFile
  • প্রভৃতি

স্বাদ বিভিন্ন শ্রেণি এবং সংস্থান কনফিগার করে।

  • ফ্ল্যাওয়ার 1 এ আপনার মেইনএ্যাকটিভিটি কিছু করতে পারে এবং ফ্ল্যাভার 2-এ বিভিন্ন বাস্তবায়ন

  • পার্থক্য অ্যাপ নাম

  • প্রভৃতি

প্রতিটি পণ্যের স্বাদে অন্যের মধ্যে নিম্নলিখিত বৈশিষ্ট্যের নিজস্ব মান থাকতে পারে, যা একই বৈশিষ্ট্যগুলির উপর ভিত্তি করে defaultConfig:

  • applicationId
  • minSdkVersion
  • targetSdkVersion
  • versionCode
  • versionName

9

আমি এখানে পার্থক্যটি কীভাবে তার সংক্ষিপ্তসারকে ছড়িয়ে দেব:

  • buildTypeহয় কিভাবে বিল্ড।
  • flavorহয় কি বিল্ড।

0

build typesইঙ্গিত করতে ব্যবহার করা হয় debug/releaseবিভিন্ন সার্টিফিকেট ও সক্রিয় সঙ্গে মোড Proguardঅথবা debuggableপতাকা।

এতে flavorsকাস্টম বৈশিষ্ট্য (উদাহরণস্বরূপ ফ্রি বা পেইড সংস্করণ), minimum and target APIস্তরগুলি, ডিভাইস এবং এপিআই প্রয়োজনীয়তাগুলি ব্যবহার করতে ব্যবহৃত হয় layout, drawableযাতে আপনার আলাদা আলাদা কোড এবং সংস্থান থাকতে পারে flavors

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.