Android x86 usb’den flashlamaya çalıştığınızda aşağıdaki hatayı alıyorsanız:
“FATAL ERROR: Bad primary partition: Partition ends in the final partial cylinder“
Çözüm için android_x86_64.iso dosyasını rufus uygulaması ile yeniden usb’ye atın sonra cihaza kurulum yapın.
Hatayı ilk aldığımda ISO’yu etcher ile yapmıştım. Sorunun diskte olduğunu düşündüm ancak bir problem yoktu. Rufus ile yeniden imajı atınca problem çözüldü.
MTP(Media Transfer Protocol) üzerinden bilgisayarımıza bağlı cihazlara terminal üzerinden nasıl erişeceğimizi anlatacağım.
Öncelikle niçin terminale ihtiyaç duyuyoruz ondan bahsedeyim. Bağlı cihazınızın içerisinde çok sayıda dosya varsa, linux taki dosya yöneticisi uygulaması (nemo, nautilus) kilitleniyor ve işlem yaptırmıyor. Bu durumda veriler üzerinde yapmak istediğimiz işlemi terminal üzerinden çok daha hızlı bir şekilde yapabiliriz.
Cihazımızı bağlayalım ve aşağıdaki komutu çalıştıralım.
cd /run/user/$UID/gvfs/
Bağlı cihazları burada görebiliriz.
cd mtp* (sizin cihaz idniz)
Bu kadar 🙂 Dosya yöneticisinde yaptığınız tüm işlemleri burada daha hızlı bir şekilde yapabilirsiniz.
Dosya sistemine erişmek için gvsf’ten yararlandık. Peki nedir bu GVsf?
GVfs(GNOME Virtual File System), GNOME’un bize sunduğu sanal bir dosya sistemidir. Böylece farklı arayüzleri (mtp,smb,ftp,sftp) sanal bir arayüzde bize sunarak kullanım kolaylığı sağlar. Bunu Windows makinalardaki takılan usb ile bilgisayardaki harddiskin aynı gibi görünmesi olarak düşünebilirsiniz.
Bugün Android’e uygulama yazarken sıkça kullandığımız bir sınıf olan Context’ten (android.content.Context) bahsedeceğim. Activity başlatmak, broadcast atmak, view güncellemek, shared prefe erişmek için her zaman context’e ihtiyaç duyarız. Peki nedir bu context? Her context aynı mıdır? Şimdi bu soruların cevabını arayalım.
Nedir Bu Her Yerde Kullandığımız Context ?
Kabaca context,
Android sistemi tarafından soyut bir şekilde bize sunulan, uygulamamız hakkında global bilgiye sahip arayüzdür. Bir nevi uygulamamızın komponentlerinin kimliğidir diyebiliriz. Uygulama sistem veya yerel bazda kaynaklara erişmek istediğinde bu kimliği kullanır işletim sistemi de bu kimliğin yeterliliğine göre işlemi başlatır.
Context sayesinde işletim sisteminin bize sunduğu uygulama özelindeki servislere erişebilir (Wifi Service, Activity Service, Location Service gibi) yine aynı şekilde uygulama seviyesinde operasyonları (activity başlatma, intent gönderme/alma gibi. ) gerçekleştirebiliriz.
Context’e birden fazla şekilde erişebiliriz. Şimdi bu erişim yollarını ve birbirinden farklarını inceleyelim.
Context Tipleri
Application Context (getApplicationContext()) – Uygulama prosesinde çalışan single instance’tır. Uygulamanız yaşadığı sürece yaşamına devam .eder. Farklı yerlerden erişim sağlasanız da aynı instance’ı elde edersiniz. Activity veya Service üzerinden getApplication() apisini çağırarak veya Context’i miras alan herhangi bir sınıftan getApplicationContext() apisini çağırarak erişebilirsiniz.
Activity/Service – ContextWrapper’dan türer ve her activity/service context kendine özgüdür. Activity yaşam döngüsüne bağlıdır. Activity’nin kendisi this contexti içerir. Bunun dışında MyActivity.this şeklinde de context’e ulaşabilirsiniz.
BroadcastReceiver – Kendisi context’e sahip değildir, broadcast için android yeni bir context oluşturmaz ancak onReceive() metodu içerisinden context sistem tarafından sağlanır. Buradaki context ReceiverRestrictedContext instance’ıdır ve iki temel fonksiyonu kapalıdır. Bunlar:
Herhangi bir broadcast receiver içerisinden başka bir receiver’a kayıt (registerReceiver()) olamazsınız.
Bir service’e bind (bindService()) olamazsınız.
Broadcast receiver içerisinde onReceive() tetiklenmesi sonucunda gelen her context’in instance’ı birbirinden farklıdır.
ContentProvider – İçerisinde context barındırmaz. Ancak oluşturulduğunda bir context atanır. Atanan context uygulama contextidir. Eğer context provider uygulama içi veya aynı proses içerisinde çalışıyorsa sağlanan contextler aynı olur. Eğer ayrı prosesler ise temsil edilen her packet için ayrı context olur.
Herkesin Context’i Kendine
Farklı context türlerinden bahsettik.Şimdi bu context’lerin neleri yapıp yapamayacağından bahsedelim. Aşağıdaki tabloda hangi türdeki contextlerin neleri yapabileceğini görebiliriz.
getApplicationContext() daha önce bahsettiğimiz gibi uygulamaya özel single instance bir context döndürür. Application komponenti, uygulamamızın global durumunu tutar.
Application context kullanmadan önce kendimize şu soruları sormalıyız?
Contexti uzun süre kullanan başka bir sınıfımız var mı? Eğer böyle bir sınıfımız varsa Activity context’i vermek memory leak’e sebep olabilir. Eğer işleminiz uzun süreli ve context’e ihtiyacınız varsa Application Context’i kullanmalıyız.
Uygulamanın görseli ile ilgili bir değişiklik yapıyor muyum?Arayüzde yaptığımız değişikliklere ait tema bilgileri Application Context’te bulunmaz. Bu da sorunlara yol açabilir. Uygulamanızın farklı activitylerinde farklı temalar kullanabilirsiniz. Özet olarak arayüz ile ilgili işlem yapıyorsak, o arayüze bağlı activity’nin contextini kullanmalıyız.
Activity Context’ini Nerelerde Kullanmalıyız ?
Activity’den oluşturulan context , activity yaşam döngüsü boyunca yaşar. Bundan dolayı activity contextini sadece o activity ile ilgili gerekli işlemlerde kullanmalıyız.
Context ile ASLA Yapmamamız Gereken Şeyler
Android her komponente uygun olacak context’i belirlemiştir. Context’i komponentler arası parametre olarak geçirmemeliyiz. Broadcast receiver ile gelen context’i activity’de, activity context’ini servis içinde kullanmamalıyız.
Memory leak oluşmaması için asla static Context değişkeni tutmamalıyız.
Eğer bunlardan birisini yaptıysak yazdığımız kodu tekrar gözden geçirmemiz faydalı olacaktır.
Eğer hangi context’i kullanmanız konusunda emin olamıyorsanız Application Context’ikullanın 🙂