Lately I’ve spent some time wrtiting an app for myself. It is supposed to let you create tasks, mark them as done/undone and then track your progress. I’ve called it “Habit Tracker” and it is available here. While writing this utility I came across a few interesting issues and this blogpost will cover one of them.
In the previous part I’ve described typical problems we have to face when developing applications on Android. I’ve also highlighted that some of them may be mitigated when data binding API is utilized properly. It’s time to dive into more details of how this promising API works.
Android application code often suffers from being more verbose than it could be. As libraries such as Android Annotations and ButterKnife have shown that’s only partially due to tediousness of Java. The recently announced Android Data Binding library can remove at least part of the boilerplate code we need to write. Since I’ve always liked Presentation Model pattern (MVVM) this is very dear to my heart. However just getting rid of a tedious code is not the main reason I’m so happy to see the new API. Let’s recap on common issues developer faces on Android and then I’ll show how using mentioned patterns with new offering from Google can mitigate them.
In the previous post you can read how to use Session object to maintain current user information through the application lifecycle. Now we’ll explore different options of implementing varying behavior depending on user type.
Every but trivial android application needs to maintain information about current user - regardless if he has authenticated or not. While this may sound easy there are still at least handful of ways one can do it - in this article I’m going to explore couple of them.
Here come the slides from a talk I gave at the last Cocoaheads Tricity meeting. It’s titled “Automate your iOS deployment a bit” and shows how we approach build and deployment automation at Bright Inventions. In just a few days we’re going to publish our “generate-ios” Yeoman generator on Github.
Recently I had an opportunity to dive into an iOS development and while I enjoy it, I miss a lot of things from the web development world. I was looking for an iOS begginer guide targeted specifically to the web developers like me, but I haven't found any. This is how the idea for this series of blog posts was born.
Time to finish the iOS layouts for web developers series with the post about events. Both the web and iOS employ similar ideas, but the set of events is distinct and we need to be aware there are different ways to interact with the classical web than with the mobile device.
Since version 1.1 of Android Gradle Plugin we can run unit test on a local JVM on our development machine. In this article I'll demonstrate how to make local resources available in unit test case.
In the fourth post in the iOS layouts for web developers series it's time for something more lightweight. We’ll go through various visual aspects of the controls and see how we can set it up, compared to CSS.