Practical Android

  When dealing with a mobile application, storage is a feature we cannot live without, whether it’s to handle relational data or persistent data in general, which is queried for different operations throughout it’s lifecycle. Most if not all mobile platforms offer SQLite database storage method which consists of a helper class and some method of initialization and querying which are both declared by the programmer. In most cases, it’s just some boilerplate code consisting of declaring table names, column names and types, primary keys, foreign keys.. and all that jazz. But we are discussing cross platform native development here, let’s see what’s what in the area of local storage in Xamarin. Ok, so the classical model of a cross platform application consists of a Core project, which is actually a .Net class library, and a couple of platform specific projects which have a link to the Core project. Each of the platform specific projects have – you guessed correctly, platform specific c

  It’s been couple of months since I’ve had a chance to post here, but it’s been an amazing time for me in terms of adapting new/old technologies for my development skills, and I have a bag full of new knowledge which has been accumulated and is waiting to be put on the blog, So in the coming weeks I’ll start posting a lot of code samples, architectural guidelines and how-to-do’s. In My professional career as a software developer, the first contact I had with OOP was with C#, back in 2007 as part of a course I took for web development which involved mostly ASP.Net, Windows forms and at the time - the diapers of WPF and Silverlight which were the latest buzz by Microsoft along with c# 3.0 and the 2.5 .Net framework. As time passed, I took on Java in order to acquire the skills which will allow me to program for the Android platform, which is my (Native) passion in the last 3 years or so. Developing for Android in Java is really something all java programmers are able to adapt to as wel

  For the last couple of weeks, I’ve been working on an App which offers the users interactive information regarding the Sela Developer Practice conference to take place on may 5th and will include dozens of lectures and international speakers which will present new technologies and trends, as well as advanced topics in the fields of Client/Server and Cloud/ALM and VS. The app communicates with couple of web services to consume the JSON data which is than processed on the client to show it from different points of view and arrange it in dynamically generated views. I took the inspiration from both the official website http://www.seladeveloperpractice.com and the app for Google’s IO which is published every year. The app shows info on the Speakers including twitter and blogs, as well as extensive info on the abstract of each session. You are welcome to try the app and rate in on Google Play: https://play.google.com/store/apps/details?id=com.selagroup.sdpmay2013

On every Google IO, many advocates for the Android platform demonstrate and teach us how to build great apps. The term “Great Apps” consists of many aspects – user experience, performance, saving battery life, not wasting expensive 3G quota and more..in this post i’ll try to demonstrate a simple way to not waste battery life in an Animation oriented activity. Let’s say that after displaying a nifty splash screen, your main activity consists of some animations which act in some sort of an infinite loop, to change pictures, articles, maybe polling data from a web service (asynctask of some sort). needless to say, that all of these processes take a lot of juice from the battery, so why worry about it? well, if we are focused in that activity, there’s not much we can do because it’s in the foreground and the user probably has some interactions with the current activity. but what happens once it’s not focused anymore? all these tasks don’t just stop themselves, it’s in our respons

  The ActionBar was introduced in Android 3.0 (API 11) and enable us to develop applications with a more fluid navigation using Fragments. Ever since, we are using the Action Bar in pretty much every application. The question is, how to be able to implement the Action bar in earlier < 3.0 API’s ? The support library which enables us to use Fragments for devices with API<3 is great and does the work just like we want and need. but what about action bar support? it’s not out of the box even in the support library. the excepted method of implementing Action bar for those earlier versions is actionbarsherlock(or ABS) just to keep things short. The ABS is an open-source expansion of the Android support library and it enables us to write application without having to make a implicit adjustment to out activities in order to support Action bars. The usage is simple: 1. download the project from the ABS website at : http://actionbarsherlock.com/ 2. inside the archive you’ll find a

     A typical mobile application will probably consume some resources from a web server using http requests. This repeated task has some drawbacks: Bandwidth has a cost, polling the same data over and over again results in a waste of user’s quota. the responsiveness and user experience is compromised once the user keeps waiting for data. If the requested data hasn’t changed on the server, then there’s no reason for us to fetch it. Of course, local caching of data is a must, but we also need to be able to refresh the data if it has changed on the server. A simple solution which comes out of the box for API 4+ is http response caching. Http response caching is a mechanism which enables us as developers to save a footprint of the response utilizing the abilities of the Http protocol. Basically, is holds a simple cache of the response which can be defined and enabled in code, and it prevents from fetching unchanged data from the server which was already fetched and processed into t

       As Android developers or developers in general, we encounter the Design Patterns paradigms pretty much in every job. Most of us as I roughly assume – go over some of the more common design patterns as an integral part in preparing for a job interview.      It is common to assume that software developers should be familiar with what design patterns are and should be able to fire couple of them and explain their usage in modern software architecture. the common patterns that you’ll probably be asked to explain are Singleton, Factory, Strategy and maybe some more exotic ones.      So the question asked, is how do classical Design patterns come handy when planning the  architecture of an android app?      The answer to this somewhat bizarre question can be divided into two mini answers : The platform which we are developing for is not important. In other words, the fact that we are dealing with an Android app is irrelevant. The design patterns which we want and should use are