Xamarin Forms Caching Strategy with Monkey Cache🐒

Today, we will learn caching technology in Xamarin.Forms as Monkey Cache.
Sometimes we need to store data in the application that we develop. For example, HTTP requests, configurations, settings, databases etc.
I need to store HTTP requests for a while during work on a project. I found Xamarin monkey cache while I search about caching strategies in that way.

What is monkey cache?

Monkey cache is a simple way to store any type of data. It supports SQLite-net, LiteDB, and a simple File Store. Monkey Cache is built against .NET Standard 2.0 and that means it is not just using with the mobile applications; it can use in any .NET projects.

How to use?

First of all, let’ s install Monkey Cache in our project from NuGet packages. You can use any file storage type in your project.

I prefer FileStore for this project. I install MonkeyCache 0.1.0.10-beta, MonkeyCache.FileStore 0.1.1.10-beta.

Data is stored in a “Barrel” or IBarrel. Don’t forget to give an application id on the barrel before storing data.

Barrel.ApplicationId = "your_unique_name_here";

If you want to do user-based cache, you can use some code like this:

Barrel.ApplicationId = "your-app-name" + UserId + DateTime.Now;

Caching a Web Request

Http request caching is very easy with Monkey Cache. We can set the expire time easily in this way:

Think like this scenario; I want to store the results of HTTP requests while if the user connected to the internet. I want to take these data from this cache if the user didn’t connect the internet and cached data didn’t expire. Now let’s take a look at the example:

https://gist.github.com/HilalSener/06f858271a13dc42b7130bd9ab3d63b5

We have seen together how to use Monkey cache today. Easy, right? You can use it over any caching scenario. Follow sample project here.

Happy Coding 🙂

You can find Monkey Cache Github source here.

You can find my previous article on Xamarin here.

.NET Core, .NET Standart ve Felsefe Taşı – Part I

Merak etmeyin, bu yazının ne Harry Potter, ne de maddeyi altına dönüştürme ile bir ilgisi yok. Bu yazı dizisinde daha çok, .NET Core ve .NET Standart’ın kendilerini, ortaya çıkmalarındaki nedenleri, ekosistemde yapacakları değişiklikleri ve bizim bu değişikliklere nasıl ayak uydurmamız gerektiği ile ilgili konuşacağız.

Giriş

Yakın zamanda .NET Core 2.0 ve ASP.NET Core 2.0 duyuruldu. Bir çok değişiklik ve güzel haber var fakat boşverin, şimdi oradan kopup, biraz daha geriye, bütün bunların başladığı zamana gidelim. Fazla değil Kasım 2014’te Microsoft, .NET Core’u (CoreFX) Open Source yaptı. Tabii kimse .NET Core’un ne olduğunu bilmiyordu. Blog yazısında, aslında bu teknolojinin içeride ASP.NET 5 (vNext) ve .NET Native’de -ki başlı başına ayrı bir konu- hali hazırda kullandıklarını, gelecekte .NET platformunun temel taşının bu yapı olacağını söylediler. Open Source olmasındaki sebep ise, .NET’in arkasında daha güçlü bir ekosistem oluşturmak ve cross-platform bir hale getirmek için hazırlıklara başlamaktı.

.NET Core’un arkasındaki ana sebep ise, .NET Framework yaklaşımının pek de doğru olmaması ve bunu değiştirmeye yönelik çalışmalar yaparken de aynı zamanda zaten olması gereken cross-platform desteğini de göz önünde bulundurmaktı. İki amaç da zamana göre daha fazla önem kazanabilir.

.NET Core’un alt yapısını anlatmadan önce size .NET Framework yaklaşımını ve yanında getirdiği problemleri biraz daha açmam gerek.

Bir Sorunun Tanımı

Yukarıdaki ekranı hatırladınız değil mi? Hiç görmediyseniz eğer ne mutlu size, bugünün şanslı 10.000 kişisinden birisiniz. Özetlemek gerekirse, yüklediğiniz bir uygulama, çalışmak için .NET Framework’ü gerektiriyor ve önce onu yüklemeniz gerek. Bunun sadece Windows içerisinde karşılaşılan bir durum olduğunu söylemiyorum, keza diğer sistemlerde yüklediğiniz paketler, başka paketleri gereksinim olarak isteyebiliyor, fakat buradaki ana sorun teknik değil. Ana sorun, yukarıdaki problemin son kullanıcı tarafından çözülmesinin beklenmesi. Aynı zamanda bu paket öyle elzem ki, bütün .NET uygulamaları* kullanıyor ve versiyonları var. Uygulama hangi versiyonu kullanıyorsa ona göre yüklenmesi gerek. Yukarıdaki “Yes” butonuna basınca sizi o paketin indirme sayfasına yönlendiriyor, siz de inen paketi kuruyorsunuz. Tabii paket kullandığınız işletim sistemi tarafından destekleniyorsa. Örneğin Windows 7 kullandığınızı varsayarsak ve açmaya çalıştığınız uygulama .NET Framework 4.6 kullanıyorsa eğer, SP1 yükseltmesini önceden yapmış olmanız gerek. Yapmamışsanız uygulama çalışmıyor. Yani bir uygulamayı kullanmak için önce sistem güncellemesi, sonra paket kurulumu ve en sonunda kullanmak istediğiniz uygulamanın kurulumunu yapmanız gerekebilir. Bu arada bütün bunları teknik bilgisi fazla olmayan birinin yapmaya çalıştını düşünürseniz, durum pek iç açıcı değil.

Diğer bir sorun, bu kütüphanenin içerisinde herşeyin olması. Siz bir uygulama yazarken sadece küçük bir kısmını bile kullansanız, bu o uygulamanın .NET Framework kullandığı gerçeğini değiştirmiyor. .NET Framework 4.6’nın kurulum paketi 62.4 MB. Kurulum sonrası boyutu 100 MB’ı aşıyor. Amacı iki sayı toplamak olan bir konsol uygulamasının çalışması için de bu kütüphanenin kurulması gerek.

Ha bu arada yukarıdaki bu iki uygulama da diğer işletim sistemlerinde çalışmıyor.

Sanırım yavaş yavaş problemin kaynağının ne olduğunu ve nasıl çözülebileceğini düşünmeye başlamışsınızdır. Öyle bir şey olmalı ki, uygulama herhangi bir dış kaynağa gereksinim duymamalı, yani kullandığı paketleri yanında götürmeli.

* = Bütün .NET Framework uygulamaları yani WinForm, WPF, ASP.NET gibi.

Bir Efsanenin Doğuşu

.NET Core işte bu fikrin hayata geçmiş hali. Tabi şu “kullandığı paketleri yanında götürmesi” kısmı için .NET Framework parçalara ayrıldı ve çoğu paket NuGet üzerinden referans edilebilir hale getirildi. En temel parçalar (CLR ve içerisindeki GC ve JIT) ise cross-platform çalışması için baştan yazıldı ve .NET Core CLR oluştu. Tabii hepsinin cross-platform çalışması için değiştirilen bir çok yaklaşım da oldu.

Peki Web?

ASP.NET 5 (vNext) yani ASP.NET Core ise, .NET Core’un üzerine ASP.NET mimarisinin bindirilmesi ile oluşmuş bir platform. Ocak 2016’ta ASP.NET 5 adı ASP.NET Core olarak değiştirildi çünkü ASP.NET  5 sanki ASP.NET 4.5’in bir üst versiyonu gibi anlaşılıyordu. Halbuki ASP.NET 5,  yapısal anlamda ASP.NET 4.5’i andırmıyordu bile ve bu insanlarda kafa karışıklığı yaratabilirdi. Bu sebeple isim değişikliğine gidildi.

Soru İşaretleri

Peki .NET Standart bunun neresinde. Bugün itibarıyla üç tane .NET platformu var; .NET Framework, .NET Core ve Xamarin. Her birisinin amacı ve kullandıkları altyapılar farklı. Tabii bu kullanılan dil aynı olsa bile oluşan paket uyuşmazlığı, yazılan kodların platformlar arası kullanılmasını engelliyor. Zaten her biri programlayan kişiye farklı API’lar sunuyor. Yani her türlü yazılan kod belirli bir platforma özel olmuş oluyor. Bu sorunu çözmek için üretilen PCL ise sorunu daha da büyük bir hale getiriyor.

Part II’de ise .NET Standart’ın ne olduğunu ve yukarıdaki probleme nasıl bir çözüm getirdiğini göreceğiz.

.NET Core, .NET Standart ve Felsefe Taşı – Part II