Εξασφάλιση του περιβάλλοντος Android

Το περιβάλλον στο Android είναι ένα από τα αντικείμενα που χρησιμοποιούνται περισσότερο και κατάχρηση. Αλλά τα περισσότερα άρθρα στον Ιστό εστιάζουν στον ορισμό του τι είναι. Δεν μπορούσα να βρω έναν καλό πόρο που μου έδωσε εικόνα και με βοήθησε να καταλάβω τη μεγαλύτερη εικόνα. Γι 'αυτό προσπάθησα να απλοποιήσω τα πράγματα με αυτό το άρθρο.

Πρόλογος

Η αποστολή μου για αυτό το άρθρο είναι να σας βοηθήσω να αποκτήσετε το Android Context. Αυτό είναι ένα από τα βασικά θέματα της ανάπτυξης Android, και σχεδόν κανένας προγραμματιστής δεν χρησιμοποιεί το περιβάλλον πλήρως και με τον τρόπο που σχεδιάστηκε.

Αρχικά δημοσίευσα αυτό το άρθρο ως μια σειρά τεσσάρων δημοσιεύσεων στον ιστότοπό μου. Εάν ενδιαφέρεστε να διαβάσετε κεφάλαιο ανά κεφάλαιο, μη διστάσετε να διαβάσετε εκεί.

Ξεκινώντας

Έχετε αντιμετωπίσει ποτέ αυτό το ερώτημα: Ποια είναι η διαφορά μεταξύ του getContext(), this, getBaseContext()και getApplicationContext(); Εάν ναι, αυτό το άρθρο θα σας βοηθήσει να ξεκαθαρίσετε το μεγαλύτερο μέρος της σύγχυσής σας.

Σημείωση: θα πρέπει να γνωρίζετε τα βασικά στοιχεία της ανάπτυξης Android, όπως η δραστηριότητα, τα θραύσματα, ο δέκτης εκπομπής και άλλα δομικά στοιχεία. Εάν είστε νέος προγραμματιστής που μόλις ξεκινά το ταξίδι σας στον κόσμο του Android, αυτό μπορεί να μην είναι το καλύτερο μέρος για να ξεκινήσετε.

Τι είναι το πλαίσιο;

Ας το παραδεχτούμε, το Context είναι μια από τις πιο κακώς σχεδιασμένες λειτουργίες του Android API. Θα μπορούσατε να το ονομάσετε "Θεός" αντικείμενο.

Ένα κιτ εφαρμογών ή εφαρμογών Android (APK) είναι μια δέσμη στοιχείων. Αυτά τα στοιχεία ορίζονται στο Manifest και αποτελούνται κυρίως από Activity (UI), Service (Background), BroadcastReceiver (Action), ContentProvider (Data) και Resources (εικόνες, συμβολοσειρές κ.λπ.).

Ο προγραμματιστής μπορεί να επιλέξει να εκθέσει αυτά τα στοιχεία σε ένα σύστημα χρησιμοποιώντας ένα φίλτρο πρόθεσης. Για παράδειγμα: αποστολή email ή κοινή χρήση φωτογραφίας. Μπορούν επίσης να επιλέξουν να εκθέσουν τα στοιχεία μόνο σε άλλα στοιχεία της εφαρμογής τους.

Ομοίως, το λειτουργικό σύστημα Android σχεδιάστηκε επίσης για να εκθέτει στοιχεία. Μερικά γνωστά είναι τα WifiManager, Vibrator και PackageManager.

Το πλαίσιο είναι η γέφυρα μεταξύ των συστατικών. Το χρησιμοποιείτε για να επικοινωνείτε μεταξύ συστατικών στοιχείων, να δημιουργείτε στοιχεία και να έχετε πρόσβαση σε στοιχεία.

Τα δικά σας εξαρτήματα

Χρησιμοποιούμε το πλαίσιο για να δημιουργήσουμε στοιχεία για τα συστατικά μας με τη Δραστηριότητα, τον Παροχέα περιεχομένου, το BroadcastReceiver και ούτω καθεξής. Το χρησιμοποιούμε για πρόσβαση σε πόρους και συστήματα αρχείων επίσης.

Το στοιχείο σας και ένα στοιχείο του συστήματος

Το περιβάλλον λειτουργεί ως σημείο εισόδου στο σύστημα Android. Ορισμένα καλά χρησιμοποιημένα στοιχεία του συστήματος είναι WifiManager, Vibrator και PackageManager. Μπορείτε να αποκτήσετε πρόσβαση στο WifiManager χρησιμοποιώντας context.getSystemService(Context.WIFI_SERVICE).

Με τον ίδιο τρόπο, μπορείτε να χρησιμοποιήσετε περιβάλλον για πρόσβαση στο σύστημα αρχείων που είναι αφιερωμένο στην εφαρμογή σας ως χρήστης στο λειτουργικό σύστημα.

Το δικό σας στοιχείο και κάποιο άλλο στοιχείο της εφαρμογής

Η επικοινωνία μεταξύ των δικών σας στοιχείων και των άλλων στοιχείων της εφαρμογής είναι σχεδόν πανομοιότυπη εάν χρησιμοποιείτε την προσέγγιση πρόθεσης-φίλτρου. Μετά από όλα, κάθε στοιχείο είναι ισότιμος πολίτης στο Android.

Ακολουθεί ένα παράδειγμα πρόθεσης που χρησιμοποιείται για την αποστολή email. Όλα τα στοιχεία που προσφέρουν αυτήν την ενέργεια πρόθεσης θα προβάλλονται στον χρήστη που μπορεί να επιλέξει τι να χρησιμοποιήσει.

Intent emailIntent = new Intent(android.content.Intent.ACTION_SEND);

Περίληψη

Ας συμφωνήσουμε ότι όλα στο Android είναι ένα στοιχείο. Το πλαίσιο είναι η γέφυρα μεταξύ των συστατικών. Το χρησιμοποιείτε για να επικοινωνείτε μεταξύ συστατικών στοιχείων, να δημιουργείτε στοιχεία και να έχετε πρόσβαση σε στοιχεία. Ελπίζω ότι ο ορισμός είναι τώρα σαφής.

Διαφορετικοί τύποι περιβάλλοντος

Υπάρχουν πολλοί τρόποι με τους οποίους μπορείτε να διατηρήσετε το περιβάλλον ( επισημαίνεται κακός σχεδιασμός ).

Τις περισσότερες φορές χρησιμοποιούμε ένα από τα ακόλουθα όταν χρειαζόμαστε περιβάλλοντα:

- Application instance as context- Activity - Instance of your activity (this) - getApplicationContext() in Activity - getBaseContext() in Activity- Fragment - getContext() in Fragment- View - getContext() in View- Broadcast Receiver - Context received in broadcast receiver- Service - Instance of your service (this) - getApplicationContext() in Service- Context - getApplicationContext() in Context instance

Διαχωρίζω τους τύπους περιβάλλοντος σε δύο κατηγορίες: Περιβάλλον περιβάλλοντος χρήστη και Περιβάλλον εκτός διεπαφής χρήστη . Αυτή η διάκριση θα σας βοηθήσει να καταλάβετε n-waysλίγο καλύτερα.

Περιβάλλον περιβάλλοντος χρήστη

Στην πραγματικότητα, μόνο το ContextThemeWrapper είναι UI Context - που σημαίνει Context + Your theme .

Η δραστηριότητα επεκτείνεται ContextThemeWrapper. Αυτός είναι ο λόγος που, όταν διογκώνετε οποιοδήποτε XML, οι προβολές σας είναι θεματικές. Εάν διογκώσετε τη διάταξή σας με περιβάλλον Non-UI, η διάταξή σας δεν θα έχει θέμα. Προχωρήστε, δοκιμάστε το.

Όταν χρησιμοποιείτε τη Δραστηριότητα ως σύμβολο κράτησης θέσης για το Περιεχόμενο, σας εγγυάται ότι χρησιμοποιείτε το Περιβάλλον περιβάλλοντος χρήστη. Εάν χρησιμοποιείτε τη μέθοδο getContext από το Fragment, χρησιμοποιείτε έμμεσα το Activity (εάν επισυνάψατε το Fragment μέσω fragmentManager στη δραστηριότητα).

Ωστόσο view.getContext(), δεν είναι εγγυημένο ότι θα είναι περιβάλλον χρήστη UI.

Εάν το View ήταν ενεργοποιημένο χρησιμοποιώντας το Layout Inflater και περάσατε το UI Context, θα λάβετε το UI Context πίσω. Αλλά αν είχε τεκμηριωθεί με τη μη διαβίβαση περιβάλλοντος περιβάλλοντος χρήστη, θα λάβετε ξανά το άλλο περιβάλλον.

UI Context- Activity - Instance of your activity (this)- Fragment - getContext() in Fragment- View - getContext() in View (if View was constructed using UI-Context)

Περιβάλλον χωρίς διεπαφή χρήστη

Anything except UI Context is Non-UI Context. Technically, anything which is not ContextThemeWrapper is Non-UI Context.

Non-UI Context is allowed do almost everything UI-Context can do (bad design spotted). But as we pointed out above, you lose theming.

Non-UI Context- Application instance as context- Activity - getApplicationContext() in Activity- Broadcast Receiver - Context received in broadcast receiver- Service - Instance of your service (this) - getApplicationContext() in Service- Context - getApplicationContext() in Context instance

Tip: All context types are supposed to be short lived except Application context. This is the one you get from your application class or from using the getApplicationContext() method when you have context access.

Summary

We have simplified it a little bit by putting Context in two buckets. UI Context is Context + Theming, and technically any class which is a subclass of ContextThemeWrapper comes in this bucket. Non-UI Context is all other types of Context.

Where to use what

The question arises: what will go wrong if you use context in the wrong place? Following are a few scenarios:

Scenario 1

Lets say you are inflating a layout and you use Non-UI Context. What may go wrong? You can guess in this case: you will not get a themed layout. Not so bad, hmm? It’s bearable.

Scenario 2

You pass UI-Context to someplace where all it needs is resource access or file system access. What can no wrong? Short Answer: Nothing. Remember, UI-Context = Context + Theme. It will gladly serve as context for you.

Scenario 3

You pass UI-Context to someplace where all it needs is resource access or file system access but it is a long operation in the background. Say downloading a file. Now what can go wrong? Short Answer: Memory leak.

If you are lucky and download completes quickly, the object is released and everything is fine. Sun is shining and birds are chirping. This is one of the most common mistakes developers make. They pass the reference of UI-Context to long living objects, and sometimes it has zero side effect.

However, sometimes Android wants to claim memory for either one of your next component’s requirements or another component’s requirements, and woooshhhh!!! You run out of memory in your app. Don’t worry, I will explain.

Memory Leak or Crash! That’s it.

Yes this is the worst case scenario when you use context in the wrong place. If you are new to the app development world, let me share some wisdom. Memory leaks are inversely proportional to your experience. Every Android developer has leaked memory. There is no shame in doing so.

Shame is when you repeat the mistake again and leak it the same way. If you leak memory a different way every time, congrats you are growing. I have explained what a Memory leak is with a short story here.

Okay I get it, but what is the relation of Context here?

Say it aloud, “Bad Design Spotted".

Almost everything in Android needs access to Context. Naive developers pass UI Context, because that’s what they have access to very easily. They pass short-living context (usually Activity context) to long living objects and before the memory/money is returned back to system, they hit a crisis. Woooshhh!!!

The simplest way to deal with this is with Async Task or Broadcast Receiver. But discussing them isn’t in the scope of this article.

Summary

  • Do you need to access UI related stuff? Use UI-Context. Inflating Views and showing dialogue are the two use cases I can think of.
  • Otherwise, Use Non UI Context.
  • Make sure you do not pass short-living context to long-living objects.
  • Pass knowledge, help people, plant trees and invite me for a coffee.

Tips and Tricks

What is the difference between this, getApplicationContext() and getBaseContext()?

This is one question every Android developer have encountered in their lives. I will try to simplify it as much as possible. Let’s take a step back and revisit the basics.

We know there are many factors in mobile devices. For instance, configuration changes all the time, and locale can change explicitly or implicitly.

All of these changes trigger apps to re-create so they can pick the right resources that are the best match to their current configuration. Portrait, Landscape, Tablet, Chinese, German, and so on. Your app needs the best possible resources to deliver the best user experience. It is the Context which is responsible for delivering those best match resources.

Try answering this question:

The user’s configuration is currently in portrait and you want to access landscape resources. Or the user locale is en and you want to access uk resources. How will you do it?

Below are some magical methods from Context:

There are many createX methods, but we are mainly interested in createConfigurationContext. Here is how you can use it:

Configuration configuration = getResources().getConfiguration();configuration.setLocale(your_custom_locale);context = createConfigurationContext(configuration);

You can get a hold of any type of Context you desire. When you call any method on the new Context you just got, you will get access to resources based on the configuration you had set.

I know it is amazing. You can send me thank you card.

Similarly, you can create a Themed Context and use it to inflate views with the theme you want.

ContextThemeWrapper ctw = new ContextThemeWrapper(this, R.style.YOUR_THEME);

Let’s come back to the tricky question we asked above and discuss Activity Context.

What is the difference between this, getApplicationContext()and getBaseContext()?

These are the possible ways you can get a hold on Context when you are in the Activity scope.

thispoints to Activity itself, our UI Context and short life context. getApplicationContext() points to your application instance which is Non-UI and long living context.

baseContext is the base of your Activity Context which you can set using a delegate pattern. You already know you can create Context with any xyz configuration you want. You can combine your xyz configuration knowledge with Base Context and your Activity will load resources as you desire.

Here is the method you can use:

@Overideprotected void attachBaseContext (Context base) {super.attachBaseContext(useYourCustomContext);}

Once BaseContext is attached, your Activity will delegate calls to this object. If you do not attach to Activity, it remains baseContext and you get Activity when you call getBaseContext.

Conclusion

We can say Context is the life of your android app. From Android’s point of view, it is your app. You can do almost nothing without Context. Without it, your app is plain Java code.

Context + Java code => Android

Good or bad, it is the design we have and we have to make the best of it. From the first part of this article, we learned that we use it to communicate between components, instantiate components, and access components.

In the next part, we learned that Context can be UI or NonUI, Short Lived or Long lived.

Following that, we learned that you need to choose context carefully otherwise you have to deal with memory leaks and other UI issues.

Finally, you saw that Context is responsible for loading best match resources for your app and you can configure it as you want. We also learned the difference between this, applicationContext and baseContext.

Many developers will advise you to use only application context. Do not use Application Context everywhere from the fear of a memory leak. Understand the root cause and always use the right Context in the right place.

You, my dear friend, are a master of Android Context now. You can suggest the next topic you want to understand. Click here to suggest.

Below are links from the original Series Mastering Android Contexton my blog.

Chapter 1

What the heck is Context? Why do we need it and what are various use cases in day to day development?

Chapter 2

Simplifying Context. We will discuss how many types of context are there and which ones are you suppose to use.

Chapter 3

Where to use UI Context and where to use Non UI-Context. How using context at wrong place may lead to memory leaks.

Chapter 4

Το περιβάλλον χρήστη μου προσφέρει επίσης πολλούς τύπους περιβάλλοντος. Ας απαντήσουμε σε αυτήν την ερώτηση και ας δούμε πώς να αποφύγουμε τις κοινές παγίδες.

Εκπαίδευση

Γνωρίζετε ότι πολλές φορές η εφαρμογή σας διακόπτεται επειδή οι προγραμματιστές σας δεν χρησιμοποιούν σωστά το περιβάλλον; Ας μάθουμε μαζί. Προσφέρω εκπαίδευση σε Android, Java και Git.

Θέλετε να μάθετε θέματα Android; Δείτε τη σειρά μας με περισσότερες από 3k θετικές ψήφους.

Μη διστάσετε να μοιραστείτε τα σχόλιά σας και τις ερωτήσεις σας. Καλή κωδικοποίηση.

Ακολουθήστε με στο Medium και το Twitter για ενημερώσεις.