Today’s post will cover basic data transfer between your iPhone app and Apple Watch app. Let’s assume that you have already created an Apple Watch extension in your project and you want to transfer some data to your watch. As an example, we will be sending Event object to our watch, so let’s have a look at Event class!
Today’s short post will cover queueing audio files using Swift. In order to do this we will be using AVQueuePlayer.
Recently I needed to show the simple rating control in one of our iOS apps - the typical row of stars, few leftmost highlighted, the more highlighted, the better the rating is. My first thoughts were wandering around star images one after another, the hell with positioning with frames or multitude of Auto Layout constraints. Nah. I ended up with something much easier and elegant.
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.