Ionic / Cordova Http Get Problem

Kategori: Ionic / Cordova
Tarih: 16th Ekim 2018

Merhabalar. İki gündür çok basit bir problemin etrafında dolaşıp duruyorum. Basit bir proje için Ionic ile uygulama geliştiriyoruz. Uygulama sunucudan bazı dataları Json olarak okuyup uygun formatta kullanıcıya gösteriyor. Geliştirmeyi tamamladık. Emulatör ve gerçek cihazlarda testlerini yaptık. Ardından marketlere yüklemeye kalktık; o da ne? Uygulama bir ekranda takılıp kalıyor. Hata da vermiyor.

Uygulama geliştiriciler için en büyük problem. Hata vermeyen/İstisna fırlatmayan kütüphaneler. Bazen bir anda eliniz kolunuz bağlanıyor. Bizim de başımızdaki durum bu mihvalde.

Ionic frameworkün en temel kütüphanelerinden HTTP kütüphane ile json datayı get olarak istiyoruz. Orada kalıyor. Hata vermiyor. Uygulama debug olarak derlenince sorun yok ama release yaptığımızda çalışmıyor. Alternatif kütüphaneleri denedik durum aynı. Bu bize şu fikri verdi: Tüm http kütüphaneleri bu noktada kaldığına göre sorun bir alt katmandan kaynaklanıyor olabilir. Handikap ise debug olarak derlenince sorun olmaması.

Kendimizi internette bu yazının başlığını ararken bulduk. Çeşitli cevaplar var ama çoğunluğu http kütüphanesinin ayarları üzerine. Daha sonra android ve ios için native dosyaları inceleyerek birşeyler yapmamız gerektiğine ikna olduk. Son olarak şuradaki soru karşımıza çıktı. Testlerde sorun olmamasına hatta Chrome tarayıcının bile sorun göstermemesine rağmen sunucunun ssl ‘i ile ilgili bir sorun olabileceği yazılmış cevap olarak da. Kontrol ettik ki bizim de sorunumuz aynı. Özellikle 10$ a alınan ssl sertifikalarında bu tür sorunlar çıkabiliyor. Çıkmayadabiliyor. Aynı ailenin ürünü farklı bir sertifika ile test etiğimizde ise onda da sorun olmadığını gördük. Http kütüphanesinin ssl sertifika kontrolü yapma diye bir ayarı var aslında ama uygulama daha öncelikli bir katmanda hataya düştüğü için o da işe yaramıyor bu durumda. O zaman çözüm olarak Ios ve Android ‘in native dosyaları değiştirilmeli. İlgili cevapta bu iş için de bir link verilmiş ama linkin uçma ihtimaline karşı buraya da yapılması gerekenleri yazıyorum.

 

Önce Android için;

Bu “project/platforms/android/CordovaLib/src/org/apache/cordova/CordovaWebViewClient.java”, yada bu “project/platforms/android/CordovaLib/src/org/apache/cordova/engine/SystemWebViewClient.java” dizindeki dosyayı (cordova sürümünüze göre değişebilir) açıp “onReceivedSslError” medhodunu bulun. Bu method ‘un içeriği de sürüme göre farklılık gösterebiliyor. Sadece şunu yapmalıyız. “if ((appInfo.flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0)” şartı ile kontrol yaptıktan sonra bu bloğun “else” kısmında “super.onReceivedSslError(view, handler, error);” buna benzer bir şekilde hata methodu çağırılıyor. Bunu by-pass edip çalışmaya devam etmesini sağlamalıyız. Bunun için bu satırı yoruma alıp altına çalışmaya devam et satırlarını eklemeliyiz (bu çalışmaya devam et komutu demin bahsi geçen if bloğunun true kısmından alınmıştır):

else{
//super.onReceivedSslError(view, handler, error);
handler.proceed();
<span class="keyword">    return</span>;
}

Sonda IOS için;

Buradaki “project/platforms/ios/Project/Classes/AppDelegate.m” dosyasını açıp altına aşağıdaki kodu ekliyoruz. Bu kod ssl sertifikası geçersiz olduğunda “sorun yok devam et” diyecek.

@implementation NSURLRequest(DataController)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
    return YES;
}
@end

IOT kartlarında multiprocessing ‘in yan etkileri

Kategori: Arduino, IOT, OrangePI, RaspberryPI
Tarih: 10th Haziran 2018

Merhaba! eğer hala bu bloğu takip eden bir okuyucu var ise ona; değilse, dağda bayırda ekolanmış ve kimsenin çekiç, örs yada üzengi kemiğine dokunamadan sıfıra yakınsamış, gitmiş bir nara gibi.

 

Bu yazıda; sosyal/toplumsal neredeyse hiçbir konuya dokunmadan; 24 hazirana çok yaklaşmış olmamız hasebiyle, şu aralar canını çıkartırcasına üzerine çullanılan siyaset konu başlığını hiç rahatsız etmeden, şuan uyur isem muhtemelen uyanamayıp üzüleceğim, sahur yemeğine kadar, yaklaşık bir buçuk saat teknik bir konu üzerine yazıp; defolup gideceğim. Her ne kadar, uzun süredir sosyal ve manevi konularda, geçmiş ve geleceğe dair içimde uzun uzun serzenme isteği olsa da. Ah ah nerede o eski sahur tebrikleri. “Vay anasını! Bu tebriği paylaşalı bile 3 sene olmuş” demekten kendini alamıyor insan. Ki o zamanlar da “Vay anasını 8 sene olmuş Kütahya ‘ya geleli, neredeyse askere gidiyorum” diye geçen zamanın hızına şahitlik ettiğimi hatırlıyorum. Ahir zamanda, zamanın bereketsizliğine her an şahidiz demek ki. Sarı ışıkla aydınlanan, anti-hijyenik ama samimi; izmarit dağlarının kokusunda sabahlara kadar muhabbet çevrilen; zaman zaman konusu, zaman zaman kendisi yüksek rakımlı; -dolu dizgin- öğrenci günleriydi. Çok sevgili Ali amcanın da dediği gibi; öğrenci pisikolojisinden çıkamamış olmamdan mütevellit…

 

Geçen hafta içerisinde, geliştirmiş olduğumuz bir cihazda buzzer ile birkaç uyarı tonu çalma ihtiyacı hasıl oldu. Önce bu ihtiyaç doğrultusunda internette yazılmış mesajlara ve örnek kodlara göz attık. Devreye bağlantı şekli -bir led gibi- gayet basit. Birçoğu mantık olarak otursa da pratikte tam istediğimizi alamadık. Tekrar tekrar test ettik. Hatta acaba bizim kartlarımızda işlemcilerimiz de mi bir sorun var diye düşünüp; bu duruma biraz kafa patlattıktan sonra fark ettik ki bu; pratik ve teori uyuşmazlığının sebebi gözden kaçırılmış olan multiprocessing meseles imiş. Hemen herkesin bu konuda şu cümle kulağındadır “Bir bilgisayar, aslında bir anda sadece bir işlem yapabilir. Ama bilgisayarlar o kadar hızlıdır ki, işlemleri arkası arkasına o kadar hızlı çalıştırır ki: biz, müzik çalma, internette gezme ve dosya indirme… hepsi aynı anda oluyor gibi görürüz.” Bu cümlede bahsedilen iş tam olarak budur. Çok işlem yapabilme kabiliyeti.

 

Arduino, NodeMCU gibi üzerinde bir işletim sistemi çalışmayan kartlar multiprocessing değildir (özel olarak bir framework yazılır ise yapılabilir). Ama RaspberryPi, OrangePi gibi daha hızlı ve üzerinde işletim sistemi koşturduğumuz kartlar aynı anda çok işlem çalıştırabilir(Bu aslında işletim sisteminin maharetidir). Şimdilik burada kalalım.

 

Önce internete önerilen şekilde geliştirdiğimiz kodu paylaşmak istiyorum.

 


import time

from pyA20.gpio import gpio

from pyA20.gpio import port

buzzer = port.PA1

gpio.init()

gpio.setcfg(buzzer, gpio.OUTPUT)

def ses_cal(f, s):

st = int((f/2) * s)

for x in range(0, st):

time.sleep(1.0 / f)

gpio.output(buzzer, 1)

time.sleep(1.0 / f)

gpio.output(buzzer, 0)

ses_cal(400, 0.5)

 

Bu kod parçacığını incelersek görürüz ki 400Hz frekansında 0.5 sn bir ton çalınmak isteniyor. Yani yarım saniye boyunca Do notası çalmak planlanmış. Multiprocessing olmayan bir sitemde düşünülür ise bir problem yok. İşlemciler çok hızlı. Buzzera tam olması gerektiği zamanlarda 1 yada 0 lar gönderilir. Peki ama multiprocessing için ne değişiyor? Onun için işin matematiğini inceleyelim.

 

400 Hz bir ton çalmak için buzzera bir saniyede 400 adet 1 ve 0 sıfır sinyali göndermek gerekir. Bu da her 1 ve 0 sinyalinin arasında 0.00125 sn olacak demek olur. En düşük hızdaki işlemciler için bile bu yakalanabilir bir aralıktır. Buzzera tam 0.00125 sn de gerekli sinyalleri gönderebilir. Eğer tek işi sadece bu ise.

 

İşte çadır tam bu noktada karışıyor. Multiprocessing bir sistemde işlemci buzzera bir sinyal gönderiyor sonra biraz da diğer işlemleri yapıyım diyor geri döndüğünde bir bakıyor eyvah 0.002 sn geçmiş. Bu da tam sizin istediğiniz tonu üretmenizi engelliyor. Daha detaya inmek gerekirse; time.sleep fonksiyonu iki sinyal arasında tam sizin istediğiniz kadar süre bırakmaz. O satır sadece “burada 0.00125 sn bekle” demektir. Sizin multiprocessing den dolayı biraz o satırdan önce biraz da sonra kaybınız olabilir. Olmayadabilir. Hatta yeteri kadar hızlı olan işlemcilerimiz time.sleep esnasında bile birkaç sefer sizin işleminize gelmiş ve biraz daha zaman var gidiyim başka işlemleri yapıp geliyim demiş olabilir. Olmayadabilir.

 

Çözüm de işte burada çıkıyor. Buzzer sizin multiprocessing den, sleep ‘den falan anlamaz. Bana hangi aralıklarla sinyal gönderirsen ben ona göre bi ton çalarım der. Siz işi time.sleep e bırakmamalı kontrollerinizi kendiniz yapmalısınız. Datetime kütüphanenizin microsecond özelliği var iki sinyal arasındaki süreyi kendiniz hesaplayıp bir sonsuz döngü icerisinde kalıp yeterli süre geçtiği anda döngüden çıkıp yeni sinyali göndermelisiniz. Bu söylediğim esaslara göre yazılmış olan kod bloğu da aşağıdadır.

 


import time

import datetime

from pyA20.gpio import gpio

from pyA20.gpio import port

buzzer = port.PA1

gpio.init()

gpio.setcfg(buzzer, gpio.OUTPUT)

def ses_cal(f, s):

st = int(f * s)

za = int((1.0 / f) * 1000000)

t = datetime.datetime.now().microsecond

s = False

for x in range(0, st):

temp = datetime.datetime.now().microsecond - t

if temp < 0:

temp += 1000000

while temp < za:

i = 0

temp = datetime.datetime.now().microsecond - t

if temp < 0:

temp += 1000000

gpio.output(buzzer, s)

s = not s

t = datetime.datetime.now().microsecond

ses_cal(400, 1)

 

Bu kod bile; kartı eğer yoğun bir işlem yükünde kullanıyorsanız tam istediğiniz sonucu veremeyebilir. Bunun için de önerim: buzzer ile kartımız arasına arduino micro gibi düşük maliyetli bir kart daha takılıp buzzer o kart ile sürülebilir.

Optimization WordPress Plugins & Solutions by W3 EDGE