Toplam 9 adet sonuctan sayfa basi 1 ile 9 arasi kadar sonuc gösteriliyor
  1. #1

    Standart Android Geliştirmeye Başlayanlar İçin Tavsiyeler

    Bu yazı Junior Android geliştiricilerin kendileri geliştirmeleri ve daha da kaliteli kod yazabilmeleri amacıyla yazılmıştır. Onlara öğrenmeleri ve denemeleri gereken içerikleri anlatan bir rehber niteliğinde olacağını umuyorum.
    Uygulamaya kütüphane eklerken dikkatli olun.



    Şimdiye kadar Android ile ilgili internette pek çok “Her Android developer’ ın bilmesi gereken kütüphaneler” başlıklı makale yayınlandı. Burada bahsedilen en popüler kütüphaneleri kullanırken bile dikkatli olarak seçmeniz gerekmektedir. Projenin gereklilikleri iyice analiz edilmeli ve projeye dahil edilecek olan kütüphane bu ihtiyaçlar doğrultusunda tercih edilmelidir. Tabi ki bu listelerde neredeyse her proje de kullanabileceğiniz (Butterknife, Picasso vb.) genel kullanıma yönelik kütüphaneleri bu işlemler dışında bırakıyorum.
    Retrofit kullanımını mutlaka öğrenin ve projelerinize dahil edin, ettirin!

    Network işlemlerinin bulunduğu, özellikle de içerisinde REST sorgularının bulunduğu projelerinizde mutlaka Retrofit kullanın. Retrofit kullanırken de dikkat edilmesi gereken en önemli nokta akıllıca kurgulanmış bir mimari kurulması olacaktır. Bu konuda bir adet blog yazısı yazmıştım önceden. Bu yazı size bir rehber niteliğinde olacaktır: https://medium.com/p/e8af23eeebc1

    RxJava nedir, ne değildir, ne amaçla kullanılır? Bu soruları sizde kendinize sormaya başlayın ve cevaplarını bir an önce araştırmaya başlayın.

    Günümüz Android dünyasının en popüler konularından bir tanesi RxJava sanırım. Herhangi bir Android projesinde pek çok işlem için kullanılabilir. Mesela bir junior Android developer için en fazla tanıdık olacak işlem sanırım AsyncTasks işlemleri olacaktır. Düzgünce kurgulanmış bir mimari ile gereksiz AsyncTasks kod bloklarından kurtulabilirsiniz. Bu konuda bende adım adım ilerliyorum ve aynı zamanda her defasında yeni şeyler öğreniyorum. RxJava’ nın kullanım yaklaşımlarından bir tanesinden bahsettiğim yazıyı da şuraya paylaşayım. Belki ilginizi çeker ve okursunuz https://medium.com/p/aa78b5023097

    Sıkıcı kod bloklarından kurtulmak amacıyla Retrolambda kullanmaya başlayın.

    Android uygulama geliştirirken fark edeceksiniz ki kod yapılarınız içerisinde gereksiz anonymous class yapılarından vb. kaynaklanan kod blokları oluşacak. Bu gereksiz uzunlukta ki kod bloklarından kurtulmak adına bir an önce Retrolambda kullanmaya başlayın: https://medium.com/p/191cc8151f85

    Düzgün bir Android proje mimarisi nasıl geliştirilebilir bu konuda kafa yormaya başlayın!

    Her zaman ana hedefiniz düzgün bir proje mimarisine sahip Android uygulaması geliştirmek olsun. Projenin geleceği açısından ve sizin de uygulamayı sağlıklı geliştirmeye devam edebilmeniz açısından projenin düzgün bir mimariye sahip olması ciddi bir önem arz etmektedir. Bu konuda internette pek çok yazı bulabilirsiniz. Ben de kendi düşüncelerimi bir blog yazısında paylaşmıştım. Bunu okuyarak öğrenmeye başlayabilirsiniz: https://medium.com/p/72f4b33252d0

    Package yapısında pek çok farklı yaklaşım olmasına rağmen şu an aktif olarak kullandığım bir package mimarisini anlattığım ayrı bir Medium blog yazısı da mevcut. Tekrardan belirtmek isterim ki bu konuda pek çok farklı yaklaşım mevcut ve ben de hala best practice nedir onu bulmaya çalışıyorum: https://medium.com/p/982f0785934

    Projenizin sadece gerekli yerlerinde event bus kütüphanelerini kullanın.

    Ben kendi projelerimde bu işlemleri gerçekleştirmesi adına Otto’ yu tercih ediyorum. Bu tarz kütüphanelere bakınca insan sanki sihirli bir şeyler oluyormuş hissine kapılıyor. İşte tam da burada bu işin büyüsüne kapılıp projenizin pek çok yerinde bunu implement etmeye başlayınca bu seferde uygulamanın pek çok yerinde callback metotları oluşmaya başlıyor ve siz de bunları kontrol etmekte zorlanıyorsunuz. Bu yüzden bu tarz yapıları projenize dahil ederken dikkatli davranmanız gerekmektedir.
    Projeniz için düzgün bir gradle yapısı kurmaya çalışın.

    Android uygulama geliştirme sürecini kolaylaştıran etmenlerden bir tanesi de planlı olarak kurgulanmış bir gradle mimarisine sahip olmak. Basit düzeyde de olsa düzgün bir mimariye sahip gradle kurgusu nasıl oluşturabilir aşağıda ki yazı da anlatmaya çalıştım: https://medium.com/p/f13e368e00a4

    Bu arada bende hala gradle’ ı nasıl daha verimli bir şekilde kullanabilirim onları araştırıyorum. Demek istediğim düzgün bir mimariye ulaşmanın sonu yok!
    Dependency Injection kavramını bir an önce anlamaya çalışın çünkü projelerinizde sizde Dagger 2 kullanmaya başlamalısınız.

    Dependency Injection nedir, ne değildir, ne amaçla böyle bir kavram üretilmiş gibi soruları sizde kendinize sorun ve bu soruların cevaplarını araştırmaya başlayın.

    Bu cevapları aldıktan sonra geçeceğiniz adım Android uygulamalarınızda Dagger 2' yi nasıl kullanabilirim, uygulamalarımın geliştirilmesi aşamalarında bana avantajları neler olacaktır gibi soruların cevaplarını aramak olacaktır. Küçük bir giriş niyetinde aşağıda ki yazıyı okuyabilirsiniz. Bu sefer bu benim yazım değil ama yakında bu konuda da bir rehber yazısı yazmayı planlıyorum https://github.com/codepath/android_...-with-Dagger-2

    Projelerinizde mümkün olduğunca kodların birbirine olan bağımlılığını azaltın!

    Bu durum sizin geliştirmiş olduğunuz Android projesinin sağlıklı bir şekilde kodlanması ve ileri de oluşabilecek değişikliklerin kontrol altına alınabilmesi amacıyla hedeflenmesi gereken ana konuların başında gelmektedir. Özellikle de kütüphanelere bağımlı olan sınıf yapılarının mümkün olduğunca Abstract olması, sizin bu tarz sağlıklı bir mimari kurmanızı kolaylaştıracaktır.

    MuratCanBatur - Medium

  2. #2

    Standart

    Tekerleği yeniden icat etmenize gerek yok. Kütüphane kullanmaktan çekinmeyin, ama bunları seçerken dikkatli olun.

    Android uygulaması geliştirirken başlangıç aşamasında bütün herşeyi kendiniz yazmalısınız gibi bir algıya kapılabilirsiniz. Bu konuda kişisel görüşüm, bu anlayışın kesinlikle yanlış olduğu yönünde.

    Uygulamalarınızı geliştirirken yerine getirmeniz gereken task’ ın çözümü için daha önceden dünyanın bir başka yerinde bir başka geliştirici veya geliştirici grupları bir çözüm üretmiş ise, bunu kullanmaktan çekinmeze gerek yok, bunda yanlış bir durumda yok ayrıca.

    Örneğin uygulamanızda network istekleri yapmanız gereken senaryolar mevcut ise, burada sizin tekrardan bir Retrofit veya Volley yazmanıza gerek yok. Doğrudan bu kütüphaneleri kullanarak işlemlerinizi gerçekleştirebilirsiniz.

    Android platformu için geliştirilen kütüphanelerin pek çoğuna buradan ulaşabilirsiniz: https://android-arsenal.com/

    Tabi burada önemli bir nokta var. Bugün itibariyle GITHUB üzerinde bir dünya kütüphane yayınlanmış durumda. Ancak bu kütüphaneleri kullanmak için hemen balıklama atlamamak lazım.

    Bir kütüphane kullanmaya karar verdiğinizde ilk olarak o reponun almış olduğu “star” sayısı oldukça önemlidir. Daha sonra repo’ da yer alan issue’ ların sayısı, bu açılmış olan issue’ lara verilen cevaplar ve bunların çözülüp çözülmediği durumu önem arz etmektedir.

    Daha çok kod okumalısınız!

    Kişisel olarak düşüncem, günlük olarak yazmış olduğunuz kod satırlarının daha fazlası kadar kod okumalı, daha fazla projeyi incelemeniz gerekmektedir. Eğer bu tarz bir çalışma prensibiniz yok ise, hemen bu yönde çalışmalara başlamanız gerekmektedir.

    Çünkü yazmış olduğunuz kodları şekillendiren ve onların gün geçtikçe daha iyi olmasını sağlayacak olan şey, kesinlikle farklı bakış açılarının var olduğunu görmeniz ve bunları inceleyerek özümsemeniz olacaktır.

    Android platformunun topluluk desteği sizlere bu konuda oldukça geniş ve içi dolu bir dünya sunmaktadır. Github’ daki açık kaynak kütüphaneleri inceleyebilir, örnek projelerin nasıl bir mimari kullanıldığını anlamaya çalışabilirsiniz. Sizlere inceleyebilmeniz için aşağıda kategorize edilmiş bir şekilde open source projelerin yayınlandığı Github reposu paylaşıyorum: https://github.com/pcqpcq/open-source-android-apps

    Kendinize temel anlamda bir kodlama standardı oluşturmayı hedef haline getirin.

    Özellikle uzun soluklu bir proje geliştiriyorsanız, veya geliştirecek olursanız bu durumun ne kadar gerekli olduğunun farkında olacaksınızdır.

    Kişisel olarak her zaman hedefim kısa, temiz ve anlaşılabilir kod yazmak olmuştur. Bunun nedeni ise, kodunuzun her zaman gelişime açık olarak ilerlemesini sağlamanız gerekliliğidir. Eğer ki bu tip bir anlayışla projelerinizi ilerletmez iseniz, süreç içerisinde ciddi sıkıntılarla karşılacaksınız, code refactor yapma süreciniz bile sıkıntıya girecektir.

    Daha üstten baktığınızda proje mimarisi üzerinden konuşmak gerekecektir. Ancak temel olarak, projenizde bir kodlama standardı yerleştirmek isterseniz, sizlere incelemeniz için aşağıda ki repoyu paylaşıyorum: https://github.com/ribot/android-gui..._guidelines.md

    Proguard kullanın.

    Evet, kabul etmek gerekir ki, Proguard işleminin gerçekleştirilmesi biraz can sıkıcı bir süreç olabiliyor. Bu yüzden de ben de dahil olmak üzere pek çok geliştirici Proguard işleminden uzak durabiliyor. Ancak bütün bu zorlukları bir kenara bırakarak Google Play’ de yayınlamış olduğunuz uygulamalarınızın kesinlikle Proguard uygulanmış olması gerekmektedir.

    Proguard’ ın temel anlamda, size yardımcı olacağı iki temel nokta bulunmaktadır. Birincisi APK’ nın boyutunu düşürmenize yardımcı olacaktır. Unutmayınız ki uygulamanın boyutu mümkün olduğunca küçük olmalıdır. İkinci yararı olduğu nokta ise, kodunuzun okunabilirliğini bozarak, reverse engineering yapılmasını belli bir aşamaya kadar zorlaştıracaktır.

    Android uygulama geliştirme temelinde yazdığım blog yazılarına aşağıda ki linkten ulaşabilirsiniz: https://medium.com/@muratcanbur

    MuratCanBatur

  3. #3

    Standart

    Yazı dizisinin bu bölümünde, Android developer’ lar arasında en çok yapılan hatalardan bahsetmek istiyorum.

    Sadece kendi cihazınızda çalışan bir uygulama yapmayın!

    Kişisel olarak Android uygulama geliştirme sürecinin en nefret edilesi durumu sanırım çeşitli sürümlerde ve ekran boyutlarında ki cihazların piyasada aktif olarak kullanılması. Bu durum tasarım aşamasından, bu tasarımın kodlanmasına kadar olan bütün süreçte problemlere yol açabilir. Eğer sadece debug yaptığınız cihazı kendinize referans olarak bir kodlama yaparsanız, büyük ihtimalle başarısız bir uygulama ortaya çıkacaktır. O yüzden bilmemiz gereken bazı temel kavramlar mevcut.

    Density-independent pixels kavramının ne olduğunu öğrenin!

    Android dünyasında farklı ekran boyutları ile başa çıkmanın en mantıklı yolu Resources dosyalarının farklı ekran boyutlarına göre veya ilgili ekran konfigürasyonuna göre ilgili klasörlerine koyulması gerekmektedir.

    Bunun yanı sıra son zamanlarda çok sıklıkla duyduğumuz Vector Drawable kavramını da araştırmanız gerekmektedir.

    Bütün bu bahsettiklerim ile ilgili detaylı bilgileri okumanız için aşağıdaki linkleri paylaşıyorum.

    https://medium.com/google-developers...d-7dc7e4efcbb3
    https://developer.android.com/guide/...s_support.html

    Sakın Main Thread’ i bloklamayın!

    Hatırlatma fayda var ki, main thread’ in tek bir amacı bulunmakta. O da UI kesintiye uğramadan kullanıcıya gösterilmesi.

    Bilindiği gibi yapılan araştırmalara göre, insan gözünün veya beyninin algılayabildiği frame oranı bir takım faktörlere bağlı olarak hesaplansa da genel olarak bellidir. Bir mobil uygulama için ise, 100 ms lik bir aralık boyunca 24 fps yenileme hızından daha düşük ise, o uygulama da performans sorunları mevcuttur.

    Android uygulamalarında ki bir başka kurala göre, bir activity için 5 saniye, bir Broadcast Receiver için ise 10 saniye boyunca yanıt alınmaz ise, ANR dediğimiz “Application Not Responding” diyaloğu meydana çıkacaktır.

    Böyle bir durumla karşılaşmamak için, uygulama içinde yapılan network işlemleri, image’ ların yüklenmesi, database sorguları gibi main thread’ i bloklayacak işlemlerin background thread içerisinde yapılması gerekmektedir.

    Bu konuda daha detaylı bilgi edinmeniz amacıyla aşağıdaki makaleyi okuyabilirsiniz.

    https://developer.android.com/traini...f-anr.html#anr

    Yaptığınız arayüzlerdeki View hiyerarşisine dikkat ediniz.

    Android uygulamalarında Layout hazırlayabilmeniz için view tanımlamalarını xml dosyaları içine koyarsınız. Daha sonra framework sizin hazırlamış olduğunuz xml dosyasını parse eder ve burada ki tag’ lere karşılık gelen nesneleri oluşturarak bir tree ortaya çıkartır. Bu işlemin yapılması aşaması da uygulamanın performansına ciddi olarak etkisi bulunmaktadır.

    Burada genel olarak bilmemiz gereken nokta, iç içe ne kadar çok view veya layout kullanırsanız, bu parse işlemi o kadar uzun süreceği ve hesaplama işlemlerinin maliyeti o kadar artacağı için uygulama olumsuz etkilenecektir. Bu yüzden xml dosyalarını hazırlarken akıllıca hareket etmekte fayda var.

    Tabi bence bu kolay bir işlem değil. Yaptığımız uygulamalarda sürekli gelişme ihtiyacı olan adımların başında gelmekte.

    Aşağıda paylaştığım video’ yu izlemenizi tavsiye ediyorum.



    Git kullanın!

    Uygulamayı geliştirien developer isterseniz sadece siz olun, veya bir ekibin parçası olun, kesinlikle Git nedir?, Git workflow nedir? sorularının cevaplarını öğrenin. Bu konularda daha detaylı bilgileri önceden yazmış olduğum Medium yazılarından öğrenebilirsiniz. Aşağıda linkleri paylaşıyorum.

    Öncelikle Git 101 tadında olan “Git Nedir?” yazısını okuyabilirsiniz: https://medium.com/turkce/yeni-ba%C5...1-ff7ea5b3eff9

    Ben zaten git kullanımını biliyorum, hatta aktif olarak kullanıyorum diyenler için de şu yazıyı okumalarını tavsiye ediyorum: https://medium.com/turkce/ba%C5%9Far...r-e026e5cc24c2

    MuratCanBur

  4. #4

    Standart

    Bir geliştiricinin en temel gayesi, yazmış olduğu kodun kalitesinin sürekli iyileştirilmesi, geliştirme sürecinin de sürekli olarak düzeltilerek ilerliyor olması gerekmektedir. Bu yazının konusu ise, bu geliştirme sürecini daha efektif bir hale nasıl getirirsiniz, bunun cevabını vermektir.

    Android Studio kullanımının inceliklerini öğrenin!

    Android Studio ile ilgili ipuçlarını, kullanım incelliklerini ve en önemlisi kısa yolları kullanmayı öğrenmeniz sizin kod yazım hızınızı ciddi manada etkileyecektir.

    En önemli noktaları öğrenebileceğiniz blog yazısını aşağıda paylaşıyorum. Bu yazıyı okuyarak ciddi manada günlük geliştirme döngünüzde değişim yaratabilirsiniz.

    50 Android Studio Tips, Tricks & Resources you should be familiar with, as an Android Developer

    Gradle config yapısını projelerinize mutlaka dahil edin!

    Dolap uygulamasında ihtiyacımız olan özelliklerden bir tanesi de hem QA ortamına hem de PROD ortamına bağlanabilen bir geliştirme ortamının kurulmasıydı. Bunun için basit bir gradle config yapısı ayarlayarak ihtiyacımız olan APK’ ları üretebileceğimiz bir mimariye sahip olduk.

    Basit anlamda debug ve release olmak üzere iki farklı APK türü için iki farklı base url yapısının kurulduğu kod parçasını paylaşıyorum.

    PHP- Kodu:
    buildTypes {
        
    debug {
            
    buildConfigField “String”“BASE_URL”\”https://api-qa.com/\""
        
    }
        
    release {
            
    buildConfigField “String”“BASE_URL”,\”https://api.com/\""

        
    }

    Gradle yapısını daha etkili kullanabilmeyi öğrenebilmeniz için önceden yazmış olduğum yazıyı aşağıda paylaşıyorum.

    let me tell you how you should build your gradle structure

    APK boyutu her zaman küçük olacak şekilde uygulamalar geliştirmeye çalışın.

    Genel olarak yeni başlayan developer’ ların yaptığı en temel hatalardan bir tanesi de, projenin içerisinde kullanılmayan resources, assets, xml veya java dosyalarının unutulması.

    Bunun yanında proguard yaptıktan sonra kullanılmayan bütün dosyaların çıkarılması için gradle config alanı içerisinde kullanabileceğimiz bir keyword bulunmaktadır.

    shrinkResources

    PHP- Kodu:
    release {
        
    minifyEnabled true
        shrinkResources true

    Serializable ve Parcelable kavramlarını öğrenin!

    Intent’ ler aracılığıyla nesnelermizi bir activity’ den bir başka activity’ e iletebilmemiz için Serializable or Parcelable arayüzlerini implement etmeliyiz.

    Çoğunlukla Serializable implemente edilmesi açısından daha basit olması yönüyle tercih edilebilir konumdadır. Ancak uygulamanın akışı büyüdükçe performans anlamında Parcelable arayüzü daha avantajlı konumdadır. Serializable yapısının daha yavaş çalışmasının temel nedeni variable tiplerini Runtime sırasında tanımlanması bir başka değişle Reflection kullanılmasıdır. Parcelable yapısında bu işlemler sizin sorumluluğunuzda olduğundan dolayı böyle bir sorun yaşanmaz.

    Biraz daha detaylı bir implemantasyon yazısı okumak isterseniz aşağıdaki stackoverflow sayfasını paylaşıyorum.

    Android: Difference between Parcelable and Serializable?

    MuratCanBatur

  5. #5

    Standart

    "Junior Android geliştiricilere tavsiyeler" yazı dizisinin 5. bölümünde Git kullanımı ve bu konuda dikkat ettiğim noktalardan bahsetmek istiyorum.

    Günümüz yazılım dünyasında versiyon kontrol sistemi olarak Git kullanımı sanırım bir standart haline geldi. Ben de hem kişisel projelerimde hem de şu an aktif olarak çalıştığım Dolap: İkinci el moda" projesinde Git tercih etmekteyim. Bunun yanı sıra projenin host edilmesi için GitHub, GitLab ve Bitbucket gibi alternatifler mevcut ve bu saydıklarım için sanırım sektör standardı desem yanılmış olmam.

    Git ve bununla ilişkili kavramlara tamamen yabancı olan arkadaşlar için aşağıda önceden yazmış olduğum “Yeni Başlayanlar için Git 101” yazımın linkini paylaşıyorum: Yeni Başlayanlar için Git 101

    Yazımın devamında ise Git kullanımı sırasında dikkat edilmesi gereken noktalardan ve takip edilmesi gereken "best practice"ler nelerdir? onlardan bahsetmek istiyorum.

    Branch temelinde çalışmaya özen gösterin!

    Projenizi geliştirirken her zaman branch’ ler üzerinden çalışmayı kendinize bir zorunluluk haline getirin. Kişisel düşüncem isterseniz tek başınıza projeyi geliştiriyor olun, isterseniz de bir ekibin parçası olarak çalışıyor olun, fark etmeksizin her zaman branch’ ler üzerinden projenizi devam ettirin. Branch temelinde çalışmanın en büyük avantajı ise, projeniz de küçük ve büyük ölçekli bütün değişiklikleri kolayca devam ettirebiliyor olmanızdır.

    “Başarılı Bir Git Branch Modeli Nasıl Oluşturulur?” başlıklı yazımı okuyarak ise, bu konuda daha ayrıntılı bilgiye sahip olabilirsiniz: Başarılı Bir Git Branch Modeli Nasıl Oluşturulur?

    Sürekli olarak commit atın.

    Uygulamada bir feature'ın yapılacak olduğunu düşünün. Bu feature için bir feature branch oluşturdunuz ve ilk commit’ i attınız. Daha sonra belli bir ilerleme daha gerçekleştirdiniz. Şimdi tekrar commit zamanı. Sürekli bu şekilde bir döngüde ilerleyerek sorunsuz bir şekilde feature branch’ inizi ilerletebilirsiniz.

    Aksi durumda ise, sürekli olarak commit atmaz iseniz, branch üzerinde bir kontrole sahip olamayacaksınız. Kod üzerinde yapılan değişikliklerin kontrolü zorlayaşacak, dolayısı ile yapmış olduğunuz bu değişikleri aksi bir durumda geri almanız imkansız hale gelecektir.

    Commit mesajlarının anlaşılabilir olması son derece önemli.

    Commit mesajlarının içeriğinin nasıl şekillenmesi gerektiğiyle alakalı internet üzerinde onlarca makale bulabilirsiniz. Bu yazılarının içeriğinden bağımsız olarak asıl önemli olan nokta, attğınız commit mesajlarının yapmış olduğunuz kod değişimini net olarak anlatıyor olması gerektiğidir.

    Sanırım takip edilebilecek en güzel yöntem commit mesajı içerisine kısa bir başlık veya task numarası ve commit içerisinde yer alan değişimlerinin özetini anlatan bir kaç cümle.

    Pull Request olmadan proje geliştirmemek en önemli hedefimiz olmalı.



    Teorik olarak bakıldığında bir projenin ilerlenmesi aşamasında Pull Request (PR) olmadan süreç devam etmemelidir. Tabi gerçek hayata döndüğümüzde bunu aktif olarak kullanabildiğimiz söylenemez.

    Burada iki durum var. Birincisi kişisel olarak geliştirilen projeler, diğeri ise ekip halinde geliştirilen projeler. Kişisel olarak geliştirilen projelerde PR sisteminin kullanılmasının en önemli yanı merge zamanı geldiğinizde yazmış olduğunuz kodu bir bütün açıdan görerek, olası sorunları bulabilmeniz, kodlama stilinin bozulup bozulmadığını kontrol edebilmeniz, yorumların durumunu görebilmeniz vs. Ekip halinde geliştirilen bir proje de zaten PR sistemi olmadan ilerlenmemeli. Bu sayede projenin kod kalitesinin korunması sağlanabilir, aynı zaman da yazılan kodlar diğer geliştiriciler tarafından da yorumlandığı için farklı görüş açıları harmanlabilir, potansiyel bug’ lar daha kolay bulunabilir.

    Base branch yapısının kurulması gerekmektedir.

    Buradaki base branch yapısı projeden projeye, şirketten şirkete göre değişiklikler gösterebilir. Her ne kadar değişimler mevcut olsa da altında yatan mantık aynıdır.

    Dolap: İkinci el moda uygulamasında prod ve master olarak isimlendirdiğimiz iki farklı base branch bulunmakta. Bazı yerlerde bunların isimleri master ve develop olarak değişim gösterebilmektedir. Prod branch'i Google play markette bulunan apk ile aynı özelliklere sahiptir. Bu branchin temel olarak özelliği, market güncellemesinin yayınlanacağı branch olmasıdır. Aynı zamanda marketteki uygulamamızda bir bug bulunduğunda ve bunun için hotfix güncellemesi yayınlanması gerekiyor ise, doğrudan prod branch’i üstünden bu süreç devam ettirilir. Bu sayede paralel olarak devam eden feature geliştirmelerinden güncellememiz etkilenmeyecektir. Master branch’ i ise geliştirmeler için oluşturulan feature branch’ lerin merge edildiği ve QA testlerinin yapıldığı branch olma özelliği taşımaktadır.

    "Başarılı Bir Git Branch Modeli Nasıl Oluşturulur?" başlıklı yazımı okuyarak ise, bu konuda daha ayrıntılı bilgiye sahip olabilirsiniz.

    MuratCanBatur

  6. #6

    Standart

    "Junior Android geliştiricilere tavsiyeler" yazı dizisinin 6. bölümünde Android uygulama geliştirmeye ilk başladığımız zamanlarda sıklıkla karşılaşılan hatalar, uygulamalarda görülen exceptionlar gibi konulardan bahsetmek istiyorum.

    ActivityNotFoundException

    Ben Android uygulama geliştirmeye ilk başladığım zamanlarda IDE olarak Eclipse kullanılıyordu. Proje içerisinde bir activity oluşturup arayüz ve fonksiyonel işlemleri düzenledikten sonra uygulamayı telefonda veya emülatörde run ettiğimizde kullandığımız startActivity() metodunun çalışmasıyla uygulamanın crash olduğunu görürdük.

    android.content.ActivityNotFoundException: Unable to find explicit activity class
    Burada aslında crash raporunu veya stack trace’ e baktığımızda mesaj gayet net olarak karşımızda duruyor. Hata mesajının bize söylediği mesaj tercüme edecek olursak, tanımlanan activity’ nin bulunamadığı sonucuna ulaşırız.

    PHP- Kodu:
    <activity
    android
    :name=".ExampleActivity"
    /> 
    Bu hatayı çözmek için yapmamız gereken ise Android Manifest dosyasına, uygulama içerisinde yer alan bütün activity’ leri tanımlamamız gerekmektedir. Android Studio yardımıyla activity’ leri tanımlıyorsanız eğer, tanımlamış olduğunuz activity’ leri Manifest dosyasına unutmanız çok zor olacaktır.



    R.layout.main Cannot Be Found / Cannot resolve symbol R

    Bu sorunu IDE üzerinde gördüğümüzde temel olarak iki tane aksiyon gerçekleştiriyoruz. Build > Clean veya Build > Rebuild Project işlemlerini gerçekleştirmeyi deneriz. Genel olarak bu aksiyonlar sorunu çözecektir ve siz de tekrardan kod yazmaya devam edebileceksinizdir.

    Eğer bu işlemlerden sonra aynı hata mesajını almaya devam ediyorsanız, yapmanız gereken şey layout dosyalarınızı kontrol etmeniz olacaktır. Büyük ihtimalle xml dosyalarının bir tanesinde hatalı bir kullanım mevcut durumdadır. Bu hatayı bulup, çözdükten sonra yukarıda işlemleri tekrarladığınız zaman hatanın çözüldüğünü göreceksiniz.

    Only the original thread that created a view hierarchy can touch its views

    Bu hata development sırasında oldukça sık karşılan bir sorundur. Anlamı ise, temel anlamda kullanmış olduğunuz view için UI thread dışında bir başka thread üzerinden işlemler yapmaya çalışmanızdır. UI elemanları ile ilgili bütün işlemlerinin doğrudan UI thread üzerinde gerçekleştirilmesi gerekmektedir. Bütün bunlara rağmen bir başka thread içerisinden bu elemanlara erişmeniz gerekecekse runOnUiThread yapısını kullanabilirsiniz.

    NetworkOnMainThreadException

    Bu hata mesajı ise, geliştirmekte olduğunuz uygulamada gerçekleşen network işlemlerinin Main Thread içerisinde yapılmaya çalışıldığı anlamına gelmektedir. Bir başka durumda ise, Main Thread’ i uzun süre bloklayan işlemler gerçekleştirdiğiniz zaman Application Not Responding hatasını alacaksınızdır.

    Bu hata mesajları ile karşılaşmamak adına Main Thread’i bloklayacak olan network request işlemleri gibi durumları gerçekleştirmek amacıyla bir başka thread yapısı tanımlamanız gerekmektedir.

    Uyarı:

    Bu yazı içerisinde kullanılan konu başlıkları için aşağıda linkini paylaştığım makale referans olarak alınmıştır.

    https://www.codementor.io/android/tu...ow-to-fix-them

    Android uygulama geliştirme temelinde yazdığım blog yazılarına aşağıdaki linkten ulaşabilirsiniz.

    MuratCanBatur

  7. #7
    Üyelik tarihi
    11.Ocak.2014
    Mesajlar
    1,597
    Blog Başlıkları
    3

    Standart

    Bütün kodların Activity veya Fragment sınıflarının içerisine yazılması

    Android geliştirmeye ilk başladığım zamanlarda benimde yaptığım gibi neredeyse bütün methodlar vs. Activity veya Fragment sınıflarının içerisine koyulması genel olarak çoğu geliştiricinin yapmış olduğu en temel hatalardan birisidir. Açık olarak söylemek gerekir ki, bu aşamalardan bende geçtim. Tabi ki bunun sonucunda birbirine girmiş bir codebase ortaya çıkmaktadır.

    Şimdi çözüm yollarından bahsetmekte yarar var. İnternette yer alan uygulama mimarileri hakkında ki yazıları okuyacak olursanız temel olarak dikkat etmeniz gereken noktalar olduğunun farkına varacaksınızdır.

    Genel olarak çoğu uygulama mimarisinde uygulayabileceğiniz bir yöntemden bahsetmek istiyorum. Burada mimari isimlerinin de çok önemli olduğunu düşünmüyorum. Projenin geliştirilmesi sırasında ki ana amacınız şu şekilde olmalıdır. Activity veya Fragment sınıfları içerisinde yer alan kod parçaları tamamen arayüzde gösterilmesi veya gösterilmemesi gereken widget durumunun ayarlanmasını koordine edecek şekilde olmalıdır. Bütün bu koordinasyon işlemini yapabilecek Presenter sınıfları oluşturarak bu işlemleri kontrol edebilirsiniz. Presenter ve Activity-Fragment sınıfları arasında ki işlemlerinin koordinasyonunu ise, iletişimi sağlayacak olan bir tane View arayüzü üzerinden koordine edebilirsiniz.

    Canlı bir örnek üzerinden yapılacak olursa, Dolap: İkinci el modauygulaması içerisinde yer alan Ödeme sayfasını yaparken oluşturduğum sınıf yapılarından örneklendirebilirim.

    İlk olarak işleme bir adet PaymentActivity sınıfı oluşturarak başladım. Bu sınıf içerisinde tamamen Android platforumuna ait olan widget’ ların durumlarının kontrolü veya adapter sınıflarının veri listelerinin doldurulması amacı taşıdım. Ayrıca herhangi bir business logic kontrolü içeren kod yazımından da uzak durmaya çalıştım diyebilirim. Bütün bu arayüzün oluşturulması işlemlerini yöneten bir tane OrderRequestPresenter isimli Presenter sınıfı oluşturdum. Bu sınıf içerisinde ise Dolap API’ sine atılan istek sonucunda dönen datalara göre arayüzde gösterilecek olan görsel elemanları kontrol edilmekte ve gerekli yönelendirmeler yapılmaktadır.

    Örneğin API’ ye yapılan istek sonucunda API bize ödeme sırasında kullanılacak olan kuponların listesini dönecektir. Burada eğer kullanılabilecek olan kuponlar var ise, ekranda kuponların listesinin bulunabileceği bir Recyclerview olacak, eğer aktif olarak kullanılacak kuponlar yok ise, bunun yerine ekranda başka bir görünüm oluşacaktır.

    İlk olarak API’den bize dönen kupon listesini, loadCouponsInfoLoadmetoduna parametre olarak gönderdik.

    Kod:
    loadCouponsInfoLoad(orderCreateResponse.getCoupons());
    Daha sonra bu metot içerisinde basit olarak listenin boyunu kontrol edilecek Activity içerisinde ki işlemlerin kontrolü için yazmış olduğumuz metotları kullanıyoruz.

    Kod:
    if (CollectionUtils.isNotEmpty(coupons)) {
        orderRequestView.couponsInfoLoaded(coupons);
    } else {
        orderRequestView.noCouponsInfoList();
    }
    OrderRequestPresenter ve PaymentActivity arasında ki işlemlerinin iletişimini sağlayacak olan bir tane interface oluşturdum. Bu interface içerisinde arayüz işlemlerinin durumlarını ifade eden metotlar bulunmakta.

    Kod:
    void couponsInfoLoaded(List<CouponResponse> couponList);
    void noCouponsInfoList();
    Bu Interface içerisinde yer alan metotları PaymentActivity içerisinde implement ettikten sonra gerekli arayüz işlemlerini yaparak, süreci tamamlıyoruz.

    Kod:
    @Override
    public void couponsInfoLoaded(List<CouponResponse>couponResponseList) {
    }
    @Override
    public void noCouponsInfoList() {
    }
    İlk bakışta çok fazla sınıf veya interface yazılıyormuş gibi bir izlemine kapılabiliriz. Ancak ana hedef noktamız yazmış olduğumuz kodların Single Responsibility kuralına uygun olarak yazılması.

    Burada bir uyarı da bulunmak istiyorum. Daha fazla araştırma yaparken fark edeceksiniz ki bahsetmiş olduğum metodun daha da ilerisinde kullanılacabilecek yapılar var. MVVM-Databinding gibi yöntemler kullanılarak da bir uygulama mimarisi oluşturabilirsiniz. Tabi bu ayrı bir yazı konusu. Yakın zamanda Dolap uygulamasında Databinding ile ilgili denemeler yapmaya başlıyor olacağım. Bu konuda ki edindiğim tecrübeleri ayrı bir blog yazısında yayınlayabilirim.

    Android uygulama geliştirme temelinde yazdığım blog yazılarına aşağıdaki linkten ulaşabilirsiniz.

    MuratCanBur

  8. #8

    Standart

     Kullanıcı Login Kontrolü
    Bu yazının ana konusunda ise, kullanıcının gerçekleştirdiği aksiyonlar için, uygulama içerisinde o kullanıcının login olup olmadığını kontrol etmenin en basit ve etkili yolunu göstermek istiyorum.

    Bu yazı içerisinde Dolap: İkinci el moda uygulaması üzerinden örnekler ve kod parçaları veriyor olacağım. Dolap: İkinci el moda uygulamasında kullanıcı bir login ekranı karşılıyor ama bu sayfada ATLA diye bir seçenek var. Eğer bir kullanıcı o sırada kayıt olmak istemez ise, bu seçenek ile uygulamayı kullanmaya başlayabilir.

    Uygulama içerisinde kullanıcının login olmasının zorunlu olduğu pek çok aksiyon bulunmaktadır. (Ürün beğenme işlemi, kullanıcı takip etme işlemi, ürün satın alma işlemi vb.) Kullanıcı bu işlemleri gerçekleştirmek istediğinde doğal olarak sizin bir Android developer olarak sizden, kullanıcının o an login olup olmadığını kontrol etmeniz, kullanıcı eğer login ise gerçekleşen aksiyon için ilgili API isteğini gerçekleştirmeniz, kullanıcı eğer login değil ise login sayfasının açılmasını sağlamanız ve kullanıcı login olduktan sonra gerçekleşen aksiyon için ilgili API isteğini gerçekleştirmeniz, ya da kullanıcı tekrardan ATLA seçeneğini kullanacak olursa, kullanıcının bulunduğu sayfaya geri dönmeniz ve hiç bir aksiyon gerçekleştirmeniz beklenmektedir.

    Yukarıda bahsetmiş olduğum senaryonun kodlanması pek çok geliştirici için basit olarak görünebilir ve gerçekten de öyledir. Burada önem verdiğim nokta ise, bu işlemleri yapan kod parçalarının doğru ve ortak bir şekilde kullanılması olacaktır. Burada ise yapılmaması gereken hatalardan bahsederek ilerlemenin daha doğru olduğunu düşünüyorum.



    İlk olarak önceki yazılarımda da bahsettiğim üzere, Activity veya Fragment sınıfları içerisinde network işlemlerinin gerçekleştiren kod parçalarının bulunmaması gerekiyor. Bu işlemlerinin gerçekleştirilmesini koordine eden Presenter sınıflarının kullanımı yazmış olduğunuz uygulamanın daha modüler olmasını sağlayacaktır. Kullanıcının login olduktan sonra bilgilerinin nasıl saklanabileceği gibi konular bir başka yazının konusu. Dolap uygulamasında bu anlamda basit bir sistem bulunmakta. Kullanıcı login olduktan sonra telefon local’ inde bir kaç değer kaydedip bunlar üzerinden gerekli kontrolleri yapıyoruz. Burada tabi şöyle bir durum. Uygulamanın bağlandığı API zaten kullanıcı gerekli Access-Token bilgisini göndermediği takdirde hata dönmekte. Tabi böyle bir sistem üzerinden de uygulama mimarisini yürütebilirsiniz ancak hem API’ yi geliştiren arkadaşlar bu konuya sıcak bakmayacaktır hem de uygulama gereksiz yere network isteğinde bulunuyor olacaktır.

    Bu kontrol durumlarını shared Preferences üzerinden yaptığımızı varsayarak yolumuza devam ettiğimizde, kodumuz üzerinde şöyle if kontrol yapıları görebiliriz.

    PHP- Kodu:
    if (MemberPrefUtil.isMemberLoggedIn()) {
    likeProductPresenter.likeProduct(productIdgetScreeningPage());

    Şimdi böyle bir kontrol yapısı ile login kontrolünü gerçekleştirebilirdim. Ancak bu şekilde ise çok ilerletilebilir bir kod mimarisi olmuyor. Çünkü bu like işlemi uygulamanın başka sayfalarında da gerçekleşiyor ve benim bu if-lese yapısını her sayfa içerisinde yapmam gerekiyor. Bu tarz bir işlemden uzak durmak adına bu kontrol işleminin Presenter sınıfı içerisinde gerçekleşmesine karar verdim.

    PHP- Kodu:
    public void likeProduct(long productId, final String screenName) {

    if (
    MemberPrefUtil.isMemberNotLoggedIn()) {
    likeView.unauthorizedUserError(DolapConstants.ACTION_LIKE);
    return;
    }

    MemberPrefUtil.isMemberNotLoggedIn() kontrol yapısı ile kullanıcının login olup olmadığını kontrol edebiliyorum. Eğer kullanıcı login ise ilgili kod parçaları çalışmaya devam ediyor, aksi takdirde kullanıcı login değil ise, bu sefer if parçacığı içerisinde kod çalışıyor return ile metot çalışmayı tamamlıyor.

    Burada LikeProductPresenter ve bu presenter sınıfının entegre olduğu Activity ve Fragment arasında ki ilişkiyi kuran bir ProductLikeView interface bulunmaktadır.

    PHP- Kodu:
    public interface ProductLikeView extends MVPView {

    void onLikeEventOccured(boolean isLiked);

    ProductLikeView, MVPView isimli bir başka interface’ i extend etmiş durumda.

    PHP- Kodu:
    public interface MVPView {

    void showProgress();

    void dismissProgress();

    void showError(RestError restError);

    void networkError();

    void timeoutError();

    void unauthorizedUserError(String actionType);

    void unauthorizedUserError();

    Bu interface içerisinde ise birden fazla metot bulunmakta. Bizim ilgilenmez gereken ise void unauthorizedUserError(String actionType).

    Dolap uygulamasında bulunan Activity ve Fragment sınıfları base olarak isimlendirdiğim sınıfları kendisine extend etmektedir. (DolapBaseActivity, DolapBaseFragment). Bu sınıflar içerisinde unauthorizedUserError(String actionType) override edilmiş durumda.

    PHP- Kodu:
    startActivityForResult(LoginContainerActivity.newIntent(getApplicationContext(), actionType), REQUEST_MEMBER_LOGIN); 
    Bu metot içerisinde de şöyle bir durum gerçekleşiyor. Uygulama içerisinde eventbus vs. gibi bir yapı kullanmadan, kullanıcının login olmadan önce gerçekleştirmeye çalıştığı aksiyonu, login olduktan sonra kaldığı yerden devam etmesini sağlamak amacıyla startActivityForResult kullanarak bu Login sayfasının açılmasını sağlıyorum.

    PHP- Kodu:
    private void returnBackToUnFinishedAction() {
    Intent intent = new Intent();
    intent.putExtra(DolapConstants.PARAM_ACTIONaction);
    setResult(RESULT_OKintent);
    finish();

    Bu sayede kullanıcı login olduktan sonra işlemin kaldığı yerden devam edebilmesi için ilgili activity veya fragment’ i uyarabilirim.

    PHP- Kodu:
    @Override
    public void onActivityResult(int requestCodeint resultCodeIntent data) {
    super.onActivityResult(requestCoderesultCodedata);

    if (
    resultCode == Activity.RESULT_OK) {
    likeProductPresenter.likeProduct();
    break;
    }

    Eğer kullanıcı ATLA işlemini bir daha gerçekleştirir ise, tekrar aynı metodu farklı bir resultCode ile uyarıyorum.

    PHP- Kodu:
    Intent intent = new Intent();
    setResult(RESULT_CANCELEDintent);
    finish(); 
    Yukarıda bahsetmeye çalıştığım konu bir uygulama içerisinde kodlanması gerçekten basit bir sistemdir. Ancak dikkatli ve özensiz bir şekilde kodlanırsa da gereksiz bir çöp kod yığınına dönüşebilir. Tabi benim bahsetmeye çalıştığım konunun da ötesinde daha düzgün bir mimari geliştirilmiş olabilir. O konuda ki yorumlarınızı da duymak ve öğrenmek isterim.

    Android uygulama geliştirme temelinde yazdığım blog yazılarına aşağıda ki linkten ulaşabilirsiniz.

    MuratCanBur - Medium.com

  9. Standart

    herzaman daha iyi olsun

Konu Bilgileri

Bu Konuya Gözatan Kullanıcılar

Şu anda 1 kullanıcı bu konuyu görüntülüyor. (0 kayıtlı ve 1 misafir)

Benzer Konular

  1. Blogunuz İçin Yararlı Olacak Tavsiyeler
    Konu Sahibi optimusprime Forum Blogcu
    Cevap: 1
    Son Mesaj : 23.Şubat.2022, 00:03
  2. Cevap: 1
    Son Mesaj : 22.Eylül.2015, 18:04
  3. OnePlus One İçin Android 5.0 Geldi!
    Konu Sahibi erkolay Forum Mobil Teknolojiler
    Cevap: 0
    Son Mesaj : 01.Ocak.2015, 16:48
  4. Blogunuz İçin Yararlı Olacak Bazı Tavsiyeler
    Konu Sahibi kazanova21641 Forum Blogcu
    Cevap: 0
    Son Mesaj : 26.Ekim.2014, 16:23
  5. Blogunuz İçin Yararlı Olacak Bazı Tavsiyeler
    Konu Sahibi WeBMasteR Forum Blogger
    Cevap: 0
    Son Mesaj : 27.Haziran.2014, 22:32

Yetkileriniz

  • Konu Acma Yetkiniz Yok
  • Cevap Yazma Yetkiniz Yok
  • Eklenti Yükleme Yetkiniz Yok
  • Mesajınızı Değiştirme Yetkiniz Yok
  •  
Linux Hosting
Yasal Bildirim
Sitemizde paylaşım yapan tüm üyeler T.C.K 20. Madde ve 5651 Sayılı Kanun'un 4. maddesinin 2. fıkrasına göre kendi konu ve mesajlarından sorumludur. Webmaster.bbs.tr hakkında yapılacak olan hukuksal ve diğer şikayetler için iletişim bölümünden iletişime geçilmesi halinde site yönetimi tarafından gereken işlemler yapılacak ve ilgili kişilere/kurumlara/vekillerine bilgi verilecektir.
Sosyal Medya