सभी टाइलों को खींचने के लिए फोर्स ग्रिडव्यू

Question

मेरे पास एक एंड्रॉइड ग्रिडव्यू है जिसमें मैं कुछ कस्टम स्क्रॉलिंग का उपयोग कर रहा हूं, इसे दो आयामों में स्क्रॉल करने के लिए - इसका मतलब है कि डिफ़ॉल्ट स्क्रॉलिंग को नहीं कहा जाता है।

मुझे संदेह है कि यह कारण हो सकता है कि ऑफ-स्क्रीन वाली पंक्तियां अदृश्य हैं। मुझे पता है कि वे वहां हैं, वे लेआउट और सबकुछ को प्रभावित करते हैं, लेकिन वे कभी आकर्षित नहीं करते हैं।

तो मेरा सवाल यह है - क्या यह लोड होने पर ग्रिडव्यू को अपने सभी टाइल्स खींचने के लिए मजबूर करने का कोई तरीका है, न केवल दृश्यमान वाले?

धन्यवाद।

संपादित करें: स्पष्ट करने के लिए - मेरी tileadapter में, मैं सेट बच्चे वास्तव में 225 मेरी GridView में करने के लिए गिनती, getChildCount() के लिए एक कॉल फिर से वापस आती है 165.

संपादित करें: यह केवल तब होता है जब की ऊंचाई ग्रिडव्यू स्क्रीन की तुलना में अधिक है - वाई अक्ष पर ऑफ-स्क्रीन वाले बच्चे आसानी से बाल गणना से घटाए जाते हैं - बच्चों के आकार को उस नंबर पर सेट करते हैं जहां वे स्क्रीन पर चुपके से फिट बैठते हैं, समस्या को हटा देते हैं, लेकिन मारता है स्क्रॉलिंग का उद्देश्य।

कोड! गतिविधि के

एक्सएमएल लेआउट:

<LinearLayout 
    xmlns:android="http://schemas.android.com/apk/res/android" 
    android:orientation="vertical" 
    android:theme="@style/Theme.Custom" 
    android:layout_width="match_parent" 
    android:layout_height="match_parent"> 

    <TextView android:id="@+id/logmessage" 
    android:theme="@style/Theme.Custom" 
    android:layout_width="fill_parent" 
    android:layout_height="25dip" 
    android:text="LogMessage"/> 

    <RelativeLayout android:id="@+id/boardwrap" 
    android:layout_weight="1" 
    android:layout_height="fill_parent" 
    android:layout_width="fill_parent" 
    android:gravity="center_vertical"> 
    <com.MyProject.GameGrid 
    android:id="@+id/board" 
    android:theme="@style/Theme.Custom" 
    android:layout_width="wrap_content" 
    android:layout_height="wrap_content" 
    android:numColumns="15" 
    android:stretchMode="none" 
    android:verticalSpacing="0dip" 
    android:horizontalSpacing="0dip" 
    android:padding="0dip" 
    android:columnWidth="20dip" 
    android:scrollbars="none"/> 
</RelativeLayout> 
<RelativeLayout 
    android:id="@+id/toolbar" 
    android:layout_width="fill_parent" 
    android:layout_height="60dip" 
    android:background="#FFFFFFFF"/> 
</LinearLayout> 

गतिविधि:

public class GameBoardActivity extends Activity { 

    public void onCreate(Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState); 
     setContentView(R.layout.gameboard); 

     GameGrid Board = (GameGrid)findViewById(R.id.board); 
     Board.setAdapter(new TileAdapter(this)); 
    } 
} 

GameGrid:

public GameGrid(Context context, AttributeSet attrs) { 
     super(context, attrs); 
     this.setNumColumns(15); 

     DisplayMetrics metrics = new DisplayMetrics(); 
     ((Activity) getContext()).getWindowManager().getDefaultDisplay().getMetrics(metrics); 
     scale = metrics.density; 
     smallSize = Math.round(20 * scale); 
     largeSize = Math.round(40 * scale); 

     columnwidth = largeSize; 
     this.setColumnWidth(columnwidth); 
     Common.DebugMessage(Float.toString(columnwidth)); 

    } 

आप मैं यहाँ एक छोटे और एक बड़े आकार को परिभाषित कर रहा हूँ देख सकते हैं - डबल स्क्रीन टैप करने से आप दोनों के बीच स्विच कर सकते हैं।

स्क्रॉल (तुम मुझे क्या पहले के साथ मदद)

if (myState == TOUCH_STATE_SCROLLING) { 
        final int deltaX = (int) (mLastX - x); 
        final int deltaY = (int) (mLastY - y); 
        mLastX = x; 
        mLastY = y; 

        int xpos = this.getScrollX(); 
        int ypos = this.getScrollY(); 

        int maxX = (columnwidth * 15) - super.getWidth(); 
        int maxY = (columnwidth * 15) - super.getHeight(); 

        if (xpos + deltaX >= 0 && xpos + deltaX <= maxX && ypos + deltaY >= 0 && ypos + deltaY <= maxY) 
        { 
         this.scrollBy(deltaX, deltaY); 
        } 
        else { 
         this.scrollTo(xpos + deltaX <= 0 ? 0 : xpos + deltaX >= maxX ? maxX : xpos + deltaX, 
             ypos + deltaY <= 0 ? 0 : ypos + deltaY >= maxY ? maxY : ypos + deltaY); 
        } 
        Common.DebugMessage(this.getChildCount()); 

       } 

Common.DebugMessage LogCat

TileAdapter को डिबग संदेशों मुद्रण के लिए सिर्फ एक सहायक विधि है:

public TileAdapter(Context c) { 
     mContext = c; 
    } 

    @Override 
    public int getCount() { 
     return 225; 
    } 

    @Override 
    public Object getItem(int position) { 
     return null; 
    } 

    @Override 
    public long getItemId(int position) { 
     return position; 
    } 

    @Override 
    public View getView(int position, View convertView, ViewGroup parent) { 
     ImageView imageView; 
     int colWidth = ((GameGrid)parent).getColumnWidth(); 
     if (convertView == null) { 
      imageView = new ImageView(mContext); 
      imageView.setLayoutParams(new GridView.LayoutParams(colWidth , colWidth)); 
      imageView.setScaleType(ImageView.ScaleType.CENTER_CROP); 
      imageView.setPadding(0, 0, 0, 0); 
     } 
     else { 
      imageView = (ImageView)convertView; 
     } 
     imageView.setImageResource(R.drawable.tile); 
     return imageView; 
    } 

Answer 1

ईमानदारी से, मेरा सुझाव प्लेटफार्म एपीआई पर झुकाव रोकने के लिए है कि इसका स्पष्ट रूप से उपयोग नहीं किया जाना चाहिए। यहां तक ​​कि यदि कुछ मतभेदों के माध्यम से आप बेस ग्रिड व्यू कोड के साथ पर्याप्त गेम खेलने में कामयाब रहे हैं ताकि आप ऐसा कर सकें जो आप करना चाहते हैं ... आप कितने आश्वस्त हैं कि आपका कोड ग्रिडव्यू कार्यान्वयन में थोड़ा बदलाव के साथ काम करना जारी रखेगा विकसित।

और वास्तव में इस तरह के गेम खेलने की कोई ज़रूरत नहीं है। ग्रिड व्यू के बारे में कुछ खास नहीं है - यह केवल एक ऐसे दृश्य का कार्यान्वयन है जो चीजों को ग्रिड में रखता है जिसे आप क्षैतिज रूप से स्क्रॉल कर सकते हैं?

यदि ग्रिड व्यू का व्यवहार आप जो चाहते हैं वह नहीं है, तो समाधान अपने स्वयं के विचार लिखना है जो आप चाहते हैं। और एंड्रॉइड के साथ यह भी आसान है क्योंकि आप ओपन-सोर्स प्लेटफार्म से आधार के रूप में ग्रिड व्यू कोड ले सकते हैं और अपने ऐप में संकलित कर सकते हैं (आपको शायद कुछ चीजों को ट्विक करने की आवश्यकता होगी क्योंकि कोड जो खड़ा है एसडीके के खिलाफ पूरी तरह से लिखा जाने की आवश्यकता नहीं है, इसलिए शायद नहीं है ... लेकिन कुछ भी ऐसा नहीं कर रहा है कि आप एसडीके के खिलाफ नियमित ऐप निर्माण में नहीं कर सकते हैं), और उसके बाद उस कोड को संशोधित करें अपने ऐप को अपने दिल की सामग्री में लाने के लिए, जो चाहते हैं उसे करने के लिए। एक अंतर्निहित विजेट के साथ लड़ने के बिना जो वास्तव में आप जो चाहते हैं वह नहीं करता है। और भविष्य में अंतर्निहित ग्रिडव्यू कार्यान्वयन में परिवर्तन होने पर आपके सावधानी से निर्मित घर के कार्ड के डर के बिना आप पर गिरने के डर के बिना।

Answer 2

एंड्रियास,

यदि आपकी समस्या बस onDraw() है मुद्दा। आप अपने GridView में एक ओवरराइड Draw(canvas) के साथ इतना आसानी से ऐसा कर सकते हैं। आपकी गतिविधि लोड होने पर प्रोसेसर आवश्यकता को बढ़ाने का दुष्प्रभाव होता है, लेकिन वांछित प्रभाव बना सकता है। इस तरह के एक ओवरराइड इस प्रकार होगा:

//This may be used in your GridView or Activity -- whichever provides the best result. 
    public void draw(Canvas canvas) 
    { int _num = myGridView.getChildCount(); 
     for (int _i = _num; --_i >= 0;) 
     { View _child = (View)myGridView.getChildAt(_i); 
      if (_child != null) 
       _child.draw(canvas); 
     } 
    } 

एक अतिरिक्त तकनीक (संपादित)

कभी कभी draw() अधिभावी प्रतिकूल प्रभाव हो सकता है। हम वास्तव में क्या करने की कोशिश कर रहे हैं, जब वे उपलब्ध हैं तो वस्तुओं को आकर्षित करने के लिए ट्रिगर करें। invalidate() ओवरराइडिंग इसी तरह से इस मुद्दे पर निर्भर करता है कि समस्या कहां है। चूंकि हमने पाया है कि draw() को ओवरराइड करने के साथ हमें अजीब परिणाम मिल रहे हैं, यह कार्रवाई का अगला कोर्स प्रतीत होता है।

//This definitely goes in your GridView 
public void invalidate() 
{ int _num = myGridView.getChildCount(); 
    for (int _i = _num; --_i >= 0;) 
    { View _child = (View)myGridView.getChildAt(_i); 
     if (_child != null) 
      _child.invalidate(); 
    } 
} 

यह है समझ में आ करने के लिए किया जाता है कि इस तकनीक को जब आप चाहते हैं एक ड्रॉ के लिए मजबूर नहीं कर सकते हैं, लेकिन केवल ओएस पता है कि यह जब यह उपलब्ध है फिर से ताज़ा करने के लिए तैयार है की सुविधा देता है। चूंकि अमान्यता स्वचालित रूप से View पेड़ को कैस्केड नहीं करती है, यदि आपके ImageView एस GridView से गहरे घोंसले हैं तो आपको समायोजित करना होगा। इसका उपयोग draw() या स्वतंत्र रूप से संयोजन के रूप में किया जा सकता है। इसके अतिरिक्त, जब invalidate() कथन के उपयुक्त प्लेसमेंट के साथ उपयोग किया जाता है, तो प्रतिक्रिया कम हो सकती है लेकिन आपकी छवियों को तैयार रखने में मदद करनी चाहिए।

समस्या बस देरी से लेआउट या ड्रा मुद्दा हो सकती है। यदि ऐसा है, तो एक आलसी लोडिंग समाधान सबसे अच्छा हो सकता है। एक आलसी लोडर सामग्री की आवश्यकता होने पर लोड करने का एक तरीका है, ताकि यह आमतौर पर कम स्मृति का उपयोग करता है, और प्रसंस्करण करता है, और इसकी आवश्यकता होने पर, क्या आवश्यक है दिखाता है। अब मैं आलसी लोडिंग पर भयानक नहीं हूं क्योंकि मुझे शायद ही कभी आवश्यकता है। लेकिन this site पर कोड का एक शानदार उदाहरण है। यह एक ग्रिड व्यू के लिए भी तैयार है।

डीम्ड लागू नहीं है (लेकिन दूसरों के लिए उपयोगी हो सकता है)

मुद्दे के केवल अन्य प्रकार मैं यह हो सकता है लगता है कि स्मृति मुद्दा रहा है जो किसी फोर्स बंद के कारण नहीं के बाहर है (और हाँ , वे मौजूद हैं)। ये देखभाल करने के लिए विशेष रूप से छद्म और दर्दनाक हैं। इन्हें स्थानांतरित करने का एकमात्र तरीका लोड या स्क्रॉल के दौरान आपके लॉगकैट में है, त्रुटि दृश्य चयनित के साथ। या आप एक संपूर्ण लॉगकैट डंप के माध्यम से जा सकते हैं (मैं आपके ऐप को पहले चलाने से पहले लॉग साफ़ करने की अनुशंसा करता हूं)।

इस तरह के मुद्दे के साथ, यह जानना महत्वपूर्ण हो जाता है कि छवि का जीवन चक्र कैसे काम करता है। यदि प्रदर्शित करने के लिए आपकी छवियों को थंबनेल आकार में छोटा कर दिया गया है, तो मैं पूर्ण आकार छवियों के साथ वास्तविक थंबनेल बनाने पर विचार करता हूं। क्योंकि रनटाइम में किसी छवि को कम करने के लिए अस्थायी रूप से इसे मूल आकार रखने से अधिक स्मृति की आवश्यकता होती है। चूंकि यह सब एक में गिर रहा है, यह एक अस्थायी समस्या हो सकती है, जो खुद को स्थायी रूप से प्रदर्शित कर सकती है। यह नाटकीय रूप से स्मृति आवश्यकताओं को कम करेगा। (उदाहरण के लिए, एक 2x2 छवि के लिए 16 बाइट्स और हेडर की आवश्यकता होती है, जबकि 4x4 छवि के लिए 64 बाइट्स और हेडर [400% आकार के लिए 400% की आवश्यकता होती है)]

इसके अतिरिक्त, System.gc() जोड़ना आपके कोड में महत्वपूर्ण स्थानों पर एक कचरा संग्रह को मजबूर कर देगा, और अधिक स्मृति को मुक्त कर देगा। (यह स्मृति मुक्त करने की गारंटी नहीं है, लेकिन इससे अधिक बार काम करता है)।

सबसे अच्छा समाधान शायद तीनों का संयोजन होगा, लेकिन इस प्रश्न के साथ हमारे पास जो कुछ है उससे थोड़ा अधिक जानकारी की आवश्यकता होगी। उदाहरण के लिए, हमें यह देखने की आवश्यकता होगी कि आपने draw() और onMeasure() और onLayout() और शायद कुछ अन्य विवरणों को ओवरराइड किया है या नहीं।

Answer 3

मैंने इसके बजाय एक और उत्तर सबमिट कर दिया है क्योंकि स्पष्टीकरण के बाद, यह मुद्दा निश्चित रूप से मेरे द्वारा विश्वास किए जाने वाले कार्यों से अलग है। पिछले जवाब में तकनीकों को भुलाया नहीं जाना चाहिए, हालांकि, और अन्य संबंधित मुद्दों के लिए एक महान संसाधन हैं, इसलिए मैं इसे वहां रख रहा हूं।

समस्या:

GridView अब ड्रॉ (थोड़े), लेकिन बार-बार एक ही छवियों को दोहरा रहा है, भयानक कलाकृतियों में जिसके परिणामस्वरूप। परिणामी कलाकृतियों इतनी बुरी हैं कि यह वास्तव में एक अच्छा संकेत नहीं देता है कि अन्य विचार भी मौजूद हैं या नहीं। यह मुद्दा वास्तव में "बहुत अधिक पारदर्शिता" के साथ किसी समस्या के कारण होता है।

Android और पारदर्शिता

एंड्रॉयड अनुमति शीर्ष दृश्य ध्यान में है वस्तुओं वर्तमान दृश्य के नीचे तैयार किया जा के लिए एक बढ़िया काम से निपटने पारदर्शिता करता है,। हालांकि, यदि सभी दृश्य पारदर्शी हैं, तो एंड्रॉइड के लिए रीफ्रेश करने की आवश्यकता होने पर सब कुछ पीछे खींचने के लिए कुछ भी नहीं है। आमतौर पर, यह कोई मुद्दा नहीं है।

आम तौर पर, डेवलपर्स हमें प्रदान किए गए टूल का उपयोग करते हैं और बस कुछ साफ चीजों को उनके साथ होने की कोशिश करते हैं। (हाँ!) और जब तक हम उनका उपयोग करते हैं, एंड्रॉइड कहता है (बहुत ज्यादा) "मुझे पता है कि क्या करना है !!" जब हम कस्टम व्यू के साथ शुरू करते हैं, हालांकि, एंड्रॉइड थोड़ा हल्का हो सकता है, खासकर जब उचित तरीके से ड्राइंग की बात आती है।

आपका ग्रिड व्यू वास्तव में GridView नहीं है। यह विस्तारितGridView है। एंड्रॉइड व्यू के विस्तार के रूप में, एंड्रॉइड इस बारे में कोई धारणा नहीं करता है कि इसे कैसे खींचा जाना चाहिए, soooo .... नतीजतन, आपके ग्रिड व्यू के लिए सामान्य अपारदर्शी पृष्ठभूमि मौजूद नहीं है। एक सोचता है, "लेकिन मेरे पास RelativeLayout में है। क्या वह पर्याप्त नहीं है?" उत्तर नहीं है। लेआउट वस्तुओं लेआउट वस्तुओं हैं। जब तक हम उन्हें निर्दिष्ट नहीं करते हैं तब तक उनके पास कोई पृष्ठभूमि नहीं होती है।

जब आप स्क्रॉलिंग और अन्य समान आंदोलनों या एनिमेशन करते हैं तो यह अधिक हो जाता है। इन मामलों में, एंड्रॉइड कैश करने की कोशिश करता है। कैशिंग दृश्य सभी दृश्यों की तरह होती है, लेकिन नतीजा यह है कि चूंकि यह सभी पारदर्शी है, आप पूरी प्रक्रिया देखते हैं। और यह कैश को साफ़ करने की आवश्यकता होने तक रीसेट नहीं होता है। यही कारण है कि उलझन और उग्र हो जाता है।

दूसरे शब्दों में, "विंडो" काला दिखाई दे सकते हैं, लेकिन वास्तव में काला नहीं है ...

समाधान (भाग I):

तो जवाब देने के लिए एक अपारदर्शी पृष्ठभूमि सेट करने के लिए है या तो विस्तारित GridView या उसके मूल दृश्यों में से एक के लिए। जब आप स्क्रॉल करते हैं तो आप जो कलाकृतियों को देख रहे हैं उन्हें हल करना चाहिए। और यह आपको ठीक से देखने की अनुमति दे सकता है कि कैसे और अन्य विचार प्रतिपादन कर रहे हैं। आखिरकार, आप पृष्ठभूमि को शीर्ष दृश्य में देखना और लागू करना चाहते हैं जिसमें सभी दृश्य शामिल हैं। पृष्ठभूमि पृष्ठभूमि रंग को सेट करने जितनी सरल हो सकती है (क्योंकि यह एक अपारदर्शी खींचने योग्य बनाता है)।

अगले चरण:

मैंने देखा है कि आप कुछ उचित कोड नहीं दिखाए हैं। मुझे वास्तव में यह जानने की ज़रूरत है कि किस प्रकार का Adapter आपका TileAdapter विस्तारित करता है और इसकी मूल जानकारी कैसे प्राप्त होती है। इसका प्रभाव इस बात पर असर डाल सकता है कि यह ड्रॉ इवेंट्स को कैसे प्राप्त और विनियमित कर रहा है। एक बार जब हम उसे जानते हैं, तो हम बाकी को ठीक करने पर काम कर सकते हैं।

मुझे यह भी जानने की जरूरत है कि आप टाइल्स की स्थिति कैसे बना रहे हैं (कोई पोजीशनिंग कोड नहीं है)। चूंकि पोजीशनिंग कोड नहीं है, इसलिए यह जानने का कोई तरीका नहीं है कि दृश्य वास्तव में जोड़े जा रहे हैं या नहीं। ImageViews के लिए डिफ़ॉल्ट व्यवहार यह है कि यदि उनमें से कम से कम कुछ हिस्सा दिखाई नहीं दे रहे हैं, तो वे पदानुक्रम में तब तक नहीं जुड़ते जब तक वे नहीं हैं। हम उस मुद्दे को मजबूर करना चाहते हैं

अंतिम परिणाम को अभी भी लेआउट, उपायों या ड्रॉ को एडजस्ट करने की आवश्यकता हो सकती है, लेकिन हम तब तक नहीं जान पाएंगे जब तक हमें क्या हो रहा है इसका सटीक प्रतिनिधित्व नहीं मिलता है।

लिए वैकल्पिक परिणाम

कुछ है, मैं अगर वे एक से ज़ूम आउट स्थिति के साथ शुरू कर दिया खेल स्क्रॉल अधिक बार है के साथ हुआ करना चाहते हैं और हम कर सकते थे स्थिति में जूम करने के लिए "चाल" .. यह आसानी से कर सकता है अपने चाइल्डकाउंट को हल करें, जैसा कि आपने कहा था कि यह स्क्रीन पर अच्छी तरह से फिट बैठता है, वे सभी आकर्षित करते हैं। और सब कुछ लोड होने के बाद प्रारंभिक ज़ूमिंग हो सकती है। फिर आपके पास एक अच्छा ग्राफिकल प्रभाव है जो दर्शाता है कि लोड पूर्ण हो गया है। ज़ूम आउट केवल एक सामान्य एनीमेशन है, इसे कार्यान्वित करना इतना आसान है। और आप जानते हैं कि आपके सभी बच्चे लोड हो गए हैं। इसके अतिरिक्त, यह सही तरीके से काम करने के लिए आपके द्वारा दर्ज कोड को सीमित कर सकता है। अंत में, यह सब एक ही गेमग्रिड ऑब्जेक्ट के साथ किया जा सकता है। :)

मुझे नहीं पता कि आपने इसके बारे में सोचा है, लेकिन मुझे लगा, "अरे, यह एक पत्थर से 2 से अधिक पक्षियों को मारने का आसान तरीका है।"

Answer 4

अपने एडाप्टर के getCount() ओवरराइड करें और अपने एडाप्टर के लिए अंतर्निहित सरणी की लंबाई वापस करें। और फिर mGrid.getChildCount के बजाय mAdapter.getCount का उपयोग करें। GetChildCount केवल दृश्यमान बच्चों को लौटाता है, जबकि GetCount आपको अपने डेटासेट में कुल बच्चे देगा।